Kinesis and Graylog Integration

Input and output integration overview

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

The Graylog plugin allows you to send Telegraf metrics to a Graylog server, utilizing the GELF format for structured logging.

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.

Graylog

The Graylog plugin is designed for sending metrics to a Graylog instance using the GELF (Graylog Extended Log Format) format. GELF helps standardize the logging data, making it easier for systems to send and analyze logs. The plugin adheres to the GELF specification, which lays out requirements for specific fields within the payload. Notably, the timestamp must be in UNIX format, and if present, the plugin sends the timestamp as-is to Graylog without alterations. If omitted, it automatically generates a timestamp. Additionally, any extra fields not explicitly defined by the spec will be prefixed with an underscore, helping to keep the data organized and compliant with GELF’s requirements. This capability is particularly valuable for users monitoring applications and infrastructure in real-time, as it allows for seamless integration and improved visibility across multiple systems.

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

Graylog

[[outputs.graylog]]
  ## Endpoints for your graylog instances.
  servers = ["udp://127.0.0.1:12201"]

  ## Connection timeout.
  # timeout = "5s"

  ## The field to use as the GELF short_message, if unset the static string
  ## "telegraf" will be used.
  ##   example: short_message_field = "message"
  # short_message_field = ""

  ## According to GELF payload specification, additional fields names must be prefixed
  ## with an underscore. Previous versions did not prefix custom field 'name' with underscore.
  ## Set to true for backward compatibility.
  # name_field_no_prefix = false

  ## Connection retry options
  ## Attempt to connect to the endpoints if the initial connection fails.
  ## If 'false', Telegraf will give up after 3 connection attempt and will
  ## exit with an error. If set to 'true', the plugin will retry to connect
  ## to the unconnected endpoints infinitely.
  # connection_retry = false
  ## Time to wait between connection retry attempts.
  # connection_retry_wait_time = "15s"

  ## Optional TLS Config
  # 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
Copy

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.

Graylog

1. Enhanced Log Management for Cloud Applications: Use the Graylog Telegraf plugin to aggregate logs from cloud-deployed applications across multiple servers. By integrating this plugin, teams can centralize logging data, making it easier to troubleshoot issues, monitor application performance, and maintain compliance with logging standards.

2. Real-Time Security Monitoring: Leverage the Graylog plugin to collect and send security-related metrics and logs to a Graylog server for real-time analysis. This allows security teams to quickly identify anomalies, track potential breaches, and respond to incidents promptly by correlating logs from various sources within the infrastructure.

3. Dynamic Alerting and Notification System: Implement the Graylog plugin to enhance alerting mechanisms in your infrastructure. By sending metrics to Graylog, teams can set up dynamic alerts based on log patterns or unexpected behavior, enabling proactive monitoring and rapid incident response strategies.

4. Cross-Platform Log Consolidation: Use the Graylog plugin to facilitate cross-platform log consolidation across diverse environments such as on-premises, hybrid, and cloud. By standardizing logging in the GELF format, organizations can ensure consistent monitoring and troubleshooting practices, regardless of where their services are hosted.

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.