Kinesis and MongoDB Integration

Input and output integration overview

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

The MongoDB Telegraf Plugin enables users to send metrics to a MongoDB database, automatically managing time series collections.

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.

MongoDB

This plugin sends metrics to MongoDB and seamlessly integrates with its time series functionality, allowing for automatic creation of collections as time series when they don’t already exist. It requires MongoDB version 5.0 or higher to utilize the time series collections feature, which is vital for efficiently storing and querying time-based data. This plugin enhances the monitoring capabilities by ensuring that all relevant metrics are stored and organized correctly within MongoDB, providing users the ability to leverage MongoDB’s powerful querying and aggregation features for time series analysis.

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"

MongoDB

[[outputs.mongodb]]
              # connection string examples for mongodb
              dsn = "mongodb://localhost:27017"
              # dsn = "mongodb://mongod1:27017,mongod2:27017,mongod3:27017/admin&replicaSet=myReplSet&w=1"

              # overrides serverSelectionTimeoutMS in dsn if set
              # timeout = "30s"

              # default authentication, optional
              # authentication = "NONE"

              # for SCRAM-SHA-256 authentication
              # authentication = "SCRAM"
              # username = "root"
              # password = "***"

              # for x509 certificate authentication
              # authentication = "X509"
              # tls_ca = "ca.pem"
              # tls_key = "client.pem"
              # # tls_key_pwd = "changeme" # required for encrypted tls_key
              # insecure_skip_verify = false

              # database to store measurements and time series collections
              # database = "telegraf"

              # granularity can be seconds, minutes, or hours.
              # configuring this value will be based on your input collection frequency.
              # see https://docs.mongodb.com/manual/core/timeseries-collections/#create-a-time-series-collection
              # granularity = "seconds"

              # optionally set a TTL to automatically expire documents from the measurement collections.
              # ttl = "360h"

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.

MongoDB

1. Dynamic Logging to MongoDB for IoT Devices: Utilize this plugin to collect and store metrics from a fleet of IoT devices in real-time. By sending device logs directly to MongoDB, you can create a centralized database that allows for easy access and querying of health metrics and performance data, enabling proactive maintenance and troubleshooting based on historical trends.

2. Time Series Analysis of Web Traffic: Use the MongoDB Telegraf Plugin to gather and analyze web traffic metrics over time. This application can help you understand peak usage times, user interactions, and behavior patterns, which can guide marketing strategies and infrastructure scaling decisions for improved user experience.

3. Automated Monitoring and Alerting System: Integrate the MongoDB plugin into an automated monitoring system that tracks application performance metrics. With time series collections, you can set up alerts based on specific thresholds, allowing your team to respond to potential issues before they affect users. This proactive management can enhance service reliability and overall performance.

4. Data Retention and TTL Management in Metrics Storage: Leverage the TTL feature for documents within MongoDB collections to auto-expire outdated metrics. This is particularly useful for environments where only recent performance data is relevant, preventing your MongoDB database from becoming cluttered with old metrics and ensuring efficient data management.

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.