SenseDeep tracks the Lambda functions in your connected AWS accounts. It aggregates per-Lambda metrics and detailed invocation logs from CloudWatch into a complete perspective for your serverless applications.
For true observability, it is important to have both a high level view of your function metrics and the ability to pin-point the exact details causing specific issues. SenseDeep provides high level metrics and graphs, while also delivering in context, exact Lambda execution logs.
Coupled with reactive monitoring support, SenseDeep provides a powerful alarm/alert mechanism so that your serverless applications can be automatically monitored 24x7x365 and proactive notification when issues arise in your application.
SenseDeep captures all AWS CloudWatch Lambda metrics and augments these with additional critical metrics calculated from your Lambda invocation history. In this manner, SenseDeep gains additional insights such as your rate of cold starts and the estimated cost for your functions.
AWS CloudWatch is a great initial store for your AWS and application log data. However, it is often difficult to locate the specific log events in the sea of log groups and streams. SenseDeep downloads and correlates your Lambda log data and then isolates log events into discrete Lambda invocation traces. These traces are analyzed for signals of potential issues and overall service trends.
When a SenseDeep alarm triggers, the relevant invocation trace is associated with the alert so you can instantly view the root cause of the alert.
SenseDeep is unique in its architecture. SenseDeep does not duplicate or replicate your log data in a 3rd party log store. Instead, SenseDeep directly accesses log data in CloudWatch and transparently caches it locally in your browser. This greatly reduces lag and wait time as SenseDeep directly and immediately downloads log events from AWS as soon as they are available. SenseDeep is thus the fastest serverless monitoring tool to react and process Lambda events.
Local caching of events in your browser also means that the user experience when browsing metrics and Lambda invocations is unmatched in speed. As the data is already in your browser -- the wait time is almost completely eliminated.
Similarly, the SenseDeep alarm Watcher directly ingests log data from CloudWatch and thus can trigger alerts the instant the alarm condition is triggered.
SenseDeep maintains a list of your Lambda functions and with high level per-Lambda metrics.
Function details include the number of invocations (events), average function duration, the number of errors, cold starts, memory used and the estimated monthly cost of the function. These metrics are for recent Lambda invocations. You can see metrics for other periods by clicking on a function to display the detailed function view.
The function list is sorted by default to elevate the Lambdas you most recently and frequently view. The Lambda priority is displayed in the list. You can sort the list differently by clicking on any of the column headings.
SenseDeep will initially cache the most recent Lambda data for all Lambdas. Thereafter, it will transparently download and cache Lambda data as required. The longer you use SenseDeep, the faster it will become as more data is cached locally in your browser. SenseDeep will prioritize the caching for Lambdas you most frequently view.
SenseDeep computes some high-level statistics for each monitored function and these are displayed in the functions list. These statistics are computed over the most recent function invocations. For the most precise Lambda metrics, click on a function and review the Lambda metrics over any time period you wish to consider.
SenseDeep has smart recommendations to assist you in tuning and optimizing your Lambda functions. SenseDeep uses machine learning and a suite of deep metrics to detect opportunities to optimize your function's performance.
SenseDeep Recommendations will advise if:
- you can reduce allocated memory to save execution costs,
- should increase memory to reduce the risk of memory exhaustion,
- should increase your AWS concurrency limit to handle your peak load,
- should use reserved concurrency to ensure a function can scale effectively,
- have too many function cold starts which are impacting the user experience,
- are experiencing function throttling which is impacting performance,
- should increase the function timeout to prevent timeouts,
- should reduce the function timeout to reduce the risk of a run-away function, or
- should migrate the a heavily used function to EC2, EKS or Fargate to save execution costs.