cloudwatch insights queries

trying to track down the reason for failed jobs run this morning.

typically i look at logs through CloudWatch/Logs/Log groups, but we see that AWS wants us to start using CloudWatch Logs Insights:

i’m documenting this process so that i can also ensure i have a clear understanding on how to efficiently query via the new logs insights.

in my lambda function, i have a devand prodalias, both of which are running at the same time daily via a cloud watch event rule:

this is important to note because it will help me identity the requestIdi need to parse through, which is is specific to either my dev or prod job.

so for example, below i have `ce6176eb-50a5–4674–8c67-a455606e71ac` and `eb6bd08b-bfdb-42e3–90cb-8d144df2e27b` request ids running, while i have another prod function starting: `c83df927–0b70–4a9f-87a6–2b72ab7e52ad`:

in the CloudWatch Log Insights UI, you have to pick your log group:

(for lambda function it will start with /aws/lambda/<name of lambda function> )

there is a default query:

for my purpose i want to sort in ascorder so i can follow the sequence of events and increase the limit clause

on the left side, you can pick specific times to fetch logs for, either in absolute or relative time. in my case, i know my jobs ran at 9:30 utc and 9:40 utc times so i will pick absolute times. you have click Run query after your selection.

i can see i have a bulk query for fetch of data that started and (it took a while):

{"data":{"bulkOperationRunQuery":{"bulkOperation":{"id":"gid:\/\/shopify\/BulkOperation\/26000000001","status":"CREATED"},"userErrors":[]}},"extensions":{"cost":{"requestedQueryCost":10,"actualQueryCost":10,"throttleStatus":{"maximumAvailable":2000.0,"currentlyAvailable":1990,"restoreRate":100.0}}}}

if you want to filter down messages to look for something specific you can do something like:

| filter @message like /(?i)(<some text>)/

( (?i) means case insensitive in regex)

or filter by requestId :

fields @timestamp, @requestId, @message
| sort @timestamp asc
| filter @requestId="<some request id>"
| limit 2000

with these simple queries, i can follow the sequence of logs without worrying about looking through several log streams in the olderLog groups format: