You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: dotnetv4/CloudWatchLogs/LargeQuery/README.md
+87-8Lines changed: 87 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,17 @@
2
2
3
3
This folder contains a .NET feature scenario that demonstrates how to perform large-scale queries on Amazon CloudWatch Logs using recursive binary search to retrieve more than the 10,000 result limit.
4
4
5
+
## Overview
6
+
7
+
CloudWatch Logs Insights queries have a maximum result limit of 10,000 records per query. This example demonstrates how to overcome this limitation by using a recursive binary search algorithm that splits the time range into smaller segments when the limit is reached.
8
+
9
+
The scenario performs the following steps:
10
+
11
+
1.**Setup**: Deploys a CloudFormation stack with a log group and log stream
12
+
2.**Data Generation**: Creates and uploads 50,000 sample log entries
13
+
3.**Query Execution**: Performs recursive queries to retrieve all logs using binary search
The key to retrieving more than 10,000 results is the recursive binary search algorithm:
92
+
93
+
1. Execute a query with the full date range
94
+
2. If results < 10,000, return them (we have all logs in this range)
95
+
3. If results = 10,000, there may be more logs:
96
+
- Get the timestamp of the last result
97
+
- Calculate the midpoint between the last timestamp and end date
98
+
- Recursively query the first half (last timestamp to midpoint)
99
+
- Recursively query the second half (midpoint to end date)
100
+
- Combine all results
101
+
102
+
This approach ensures all logs are retrieved by progressively narrowing the time ranges until each segment contains fewer than 10,000 results.
103
+
104
+
### Timestamp Precision
105
+
106
+
The algorithm uses millisecond precision for timestamps to ensure accurate splitting and prevent duplicate or missing log entries. Each query adjusts the start time by 1 millisecond to avoid overlapping results.
107
+
108
+
## Expected Output
109
+
110
+
When running the scenario, you'll see output similar to:
0 commit comments