How can we get the minimum and maximum lambda execution time by querying cloudwatch? Note we only want to query for the successful execution and skip the failed ones.
This is my first attempt:
fields @message
| filter @type = "REPORT"
| stats min(@duration) as MinimumTime,
max(@duration) as MaximumTime
Response:
It does generates the Min and Max execution time, but it includes the failed lambda executions.
Partially working solution: as the failed lambda executions has log both for exception
and report
; and successful execution only has report
, the following query will remove the failed executions and list only the requestId
of successful executions:
fields @message
| filter @message like "REPORT" or @message like "[ERROR]"
| filter ispresent(@requestId)
| stats count(*) as requestIdLogCount by @requestId
| filter requestIdLogCount == 1
Response:
Now is it possible to update the above query with some sort of subquery or something else where I can use the @requestId
to filter out the log and generate report only with the successful lambda execution? Here is another query which is using the @requestId
from above query
fields @message
| filter @type = "REPORT"
| filter @requestId in ["a458412a-95e7-5023-842e-1dbe8f58a876", "082db28d-8f43-5f83-9a72-ee1985861515"]
| stats min(@duration) as MinimumTime,
max(@duration) as MaximumTime
The better way would be to use Lambda Metrics as suggested by @jarmond. CloudWatch metrics can easily used in CloudWatch Dashboards and are much, much faster to query (while also costing less).
Using the CloudWatch Logs query has a few caveats:
So the best advice would be to use the provided metrics and if that doesn't suffice, only then use log file scanning.
Since you only want the successful invocations, the lambda function itself could write the metrics at the end of the request.
To the metrics query:
CloudWatch Logs can't cross reference other logs, so there is no sub-query functionality. You can only filter upon information in the same log line without cross-referencing other log lines.
If you insist in the use case, you would need to parse the logs yourself by using streams or log filters. General idea:
Alternative would be to export CW Logs to S3 and use Athena or other products to do complex queries...