Mastering Log Group-Level Subscription Filters for Real-Time Observability
In today's fast-paced cloud environments, the ability to process logs in real-time is crucial for observability and incident response. Log group-level subscription filters allow you to stream logs directly to services like Amazon Kinesis Data Streams, AWS Lambda, and others. This capability not only enhances your monitoring but also enables you to act on log data as it arrives, rather than waiting for batch processing. The logs are base64 encoded and compressed with gzip, ensuring efficient data transfer.
To set up a subscription filter, you first need to create a destination stream and an IAM role that grants CloudWatch Logs permission to send data to your stream. When you configure the subscription filter, you can specify a filter pattern to control which log events are sent. For example, you might only want to capture logs from specific user types. Be mindful of the volume of log data generated; if your stream lacks sufficient shards, throttling will occur, leading to dropped log events after 24 hours. To mitigate this risk, consider using on-demand capacity mode for your Kinesis Data Streams and monitor your stream with CloudWatch metrics to adjust your configuration as needed.
In production, always calculate the expected log volume before creating your stream. Use random distribution for your subscription filter to avoid throttling issues. Keep an eye on the DeliveryThrottling metric to ensure your setup can handle the load. These steps will help you maintain a robust logging architecture that scales with your application’s demands.
Key takeaways
- →Create a destination stream before setting up subscription filters.
- →Use IAM roles to grant CloudWatch Logs permission to send data to your stream.
- →Monitor your Kinesis stream with CloudWatch metrics to detect throttling.
- →Specify random for distribution when creating subscription filters to reduce throttling risk.
- →Adjust your filter pattern to match the capacity of your Kinesis stream.
Why it matters
Real-time log processing enables faster incident response and improved system observability. This capability can significantly reduce downtime and enhance your application's reliability.
Code examples
aws logs put-subscription-filter \ --log-group-name "CloudTrail/logs" \ --filter-name "RootAccess" \ --filter-pattern "{$.userIdentity.type = Root}" \ --destination-arn "arn:aws:kinesis:region:123456789012:stream/RootAccess" \ --role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisRole"aws iam create-role --role-nameCWLtoKinesisRole--assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.jsonaws kinesis create-stream --stream-name "RootAccess" --shard-count 1When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsSimple, affordable cloud — VMs, Kubernetes, and managed databases in minutes. Trusted by 600,000+ developers. Spin up a Droplet in 60 seconds.
Try DigitalOcean →Unlocking Root Cause Analysis with AWS DevOps Agent's Multi-Agent Reasoning
Root cause analysis can be a nightmare in complex systems. AWS DevOps Agent leverages a multi-agent architecture to streamline incident investigations, using a topology graph to provide crucial context throughout the lifecycle.
Automate Root Cause Analysis with AWS DevOps Agent and Datadog
Root cause analysis can be a time-consuming process, but it doesn't have to be. With the AWS DevOps Agent, you can automate investigations triggered by Datadog alerts, correlating signals across observability backends in minutes.
Building an Autonomous SRE with AWS DevOps Agent
Imagine an SRE that never sleeps. The AWS DevOps Agent autonomously investigates incidents, correlates telemetry, and recommends fixes without constant human oversight. This article dives into how it works and what you need to know to implement it effectively.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.