Sigma is the 18th letter of the Greek alphabet and is equivalent to English letter ‘S’. In mathematics, the upper case sigma is used for the summation notation.
Following on this definition, SLAppForge has created the world’s first serverless development tool Sigma, a summation of multiple application components to cover most of the aspects of serverless development life cycle including; coding, testing, debugging, managing resources and monitoring.
Sigma, the first Truly Serverless DevKit!
Say hello to a seamless serverless experience — with resources, triggers, operations and so on!
SigmaDash is the newest addition to the SLAppForge’s serverless tools stack which gives you the ability to monitor your functions and projects.
- Preventing over allocation & under allocation of resources
No one is perfect in estimating the resources(memory, cpu, timeout) requirement for the functions we write. In serverless, your monthly bill is an equation of memory, CPU & running time. Hence, both over allocation & under allocation of resources could cost you in terms of money(Under allocation could increase running time). Monitoring helps you to find the sweetest spot for these parameters for a particular function that bears a very specific application logic.
2. Identifying Trends
Monitoring and analyzing various stats of functions helps you to identify the trends, which gives you the necessary information to make ongoing enhancements.
3. Identifying Bugs & Flaws
It is hard to write a 100% bug free code or to handle all the edge cases of your business logic. So better to keep an eye on your functions to identify and patch when they fail to handle certain requests.
Lambda programming errors that could cost you thousands of dollars a day!
This is a real story. One that is still unfolding.. Within a week we accumulated a bill close to $10K due to a…
We could easily identify & prevent this if we had SigmaDash at that time. 😕
4. Identifying attacks and security breaches.
Make use of graphical tools, logs to monitor and identify security attacks before they take your systems down.
SigmaDash, the tool to keep an eye on your functions!
SigmaDash is the newest component of the SLAppForge serverless stack to accomplish all above goals by putting a minimum effort.
SigmaDash has two types of monitor-able components.
Functions are the exact representation of AWS Lambda functions inside SigmaDash. There is an one to one mapping between SigmaDash functions and AWS Lambda functions.
Project is a collection of functions. With projects, you get the ability to logically group functions and monitor aggregated stats. There is an one to many mapping between SigmaDash projects and AWS Lambda functrions.
SigmaDash Home Screen
SigmaDash home screen has two sections, pinned projects and pinned functions. You can pin most concerned functions and projects to home screen and quickly jump between them more conveniently.
For each function or project, SigmaDash generate graphical representations for following metrics.
Number of times, a function or a set of functions are invoked as a result of an event or a direct invocation api call. This chart counts all invocations regardless of success or failure of the respective invocation. This graph is useful when determining trends.
Memory usage of the function containers per each invocation. This graph is useful in determining over allocation or under allocation of resources.
Duration taken by each invocation of the function. This graph combined with the memory graph can be used to determine the sweet spot for resource allocation to minimize the cost.
Each AWS account has certain concurrent limits imposed by AWS to prevent misusing their resources. ie. By default, AWS Lambda limits the total concurrent executions across all functions within a given region to 1000. This graphs shows number of throttled invocations due to exceeding these limits. Based on this graph, we can either adjust our source code/ application logic to limit number of function invocations or request AWS to lift account limits.
Number of invocations that failed due to,
- Handled exceptions (for example, context.fail(error))
- Unhandled exceptions causing the code to exit
- Out of memory exceptions
- Permissions errors
SigmaDash generates this graph utilizing following equation with AWS Lambda pricing.
Cost = Allocated Memory * Invocation time rounded up to nearest 100ms
In addition to these metrics, SigmaDash comes with Sigma’s log monitoring component SigmaTrail built in.
SigmaDash Metrics controllers
SigmaDash, by default update metrics of the function or project with an interval of 1 minute. However, you can turn of auto refresh or configure update interval.
You can configure the time range to consider only the function invocations of a targeted time period when generating metrics. We usually don’t impose limits on this range. But it is advisable not to select larger ranges if you have frequent invocations within the selected range.
SigmaDash Graph Controllers
SigmaDash allows you to analyse metrics using two types of charts; line charts, bar charts. Additionally you get the ability to zoom in/out chart to get a better fine tuned view.
Log Monitoring with SigmaTrail
SigmaTrail is the log monitoring component that comes with both Sigma IDE and SigmaDash.
In sigma, we have categorized logs into two types.
1. Test Logs [TEST]
Test logs are the type, that will be generated in realtime when you execute a test case within the IDE. These logs will include the result/response of the test execution and the generated logs in line.
2. Prod Logs [PROD]
Prod logs are the type, that will be generated when you invoke the lambda function through one of your event sources. (ie: Api Gateway, S3 event etc.) These logs does not include the result/response of the execution.
We refer log request as the group of log lines which are generated during a one cycle of execution of lambda function.
1. Log Request header
Log request header gives you a quick insight about the Log Request. The format of the header is as follows.
[Date] [Time] [Request Id] [No of log lines] [TEST / PROD]
You can click on Log request header to expand or collapse the log lines.
2. Test execution result
This section is only applicable for TEST logs. If the result can be parsed to a JSON, Sigma will show you the response in an expandable JSON tree.
3. Log line
Log line is a single line of a console log generated by lambda code
4. Stack Trace
Stack trace is a report of the active stack frames at the time of an error is thrown. This will be useful when debugging an application.
5. Resource Utilization
This section indicates the time taken to execute the function logic and the memory utilized to process the respective request.
Sigma Trail Controllers
Sigma trail header has following controls to fine tune your logs view.
1. Lambda Selector
Sigma Trail shows only trails related to one particular function within one screen. If you want to switch sigma trail to show trails of a different function, click on this button to get a list of available lambda functions.
In addition to this selector, switching between editor tabs will automtically switch Sigma Trail to show logs of the focused function.
2. Download Trail
Sigma allows you to download logs in following two formats.
3. Clear Logs
If you are not interested about the visible logs, you can hide visible logs by this button.
4. Auto Scroll
Sigma automatically scrolls the trail for you. Whenever a new Log request is appended, trail will get automatically scrolled and expand the new log request. You may switch on/off this feature by toggling this button.
5. Search logs
You can filter Sigma trails by using Cloudwatch filter pattern and syntax.
This will give you an effect similar to tailing with grep.
Close the sigma trail panel.
Resizing logs view
If you want to make more room for your code, you may resize sigma trail by holding and dragging the header as below.
Navigating over Old Log requests
Sigma by default shows you only the latest 15 log requests.
To view older logs, you may use following controllers.
View Older Logs
This will load 15 more older logs to sigma trail.
Hide Older Logs
This button will take you back to the 15 latest logs only mode.
Controlling Sigma’s Log fetching behavior
By default Sigma continuously polls for new logs from Cloudwatch. If you wish to control this behavior, you may use following set of buttons.
Tune On/Off Real-time logs
Turning of Real-time logs will stop Sigma from automatically polling for new logs.
View Older Logs
In non Real-time mode, use this button to request for newer log requests.
Some of these components and features are available only within the Sigma IDE & not applicable for SigmaDash.
Creating Projects in SigmaDash
A project in SigmaDash is a collection of functions. You can create a project by clicking on Create Project button of Project page of SigmaDash.
SigmaDash provides two ways to create a project.
- Create an empty project from scratch.
In this mode, you just start with a name and a description for your project.
2. Start with a CloudFormation project.
In this mode, you can start your project with an existing CloudFormation project. SigmaDash will automatically import all the function defined in the specified CloudFormation project to your SigmaDash project.
Attaching Function to Project
Regardless of how you started the project, you can attach new functions to your project by navigating to project home screen. Once you attach a function, the project metrics will get updated automatically.
So, this is how we at SLAppForge have initiated to streamline serverless monitoring. This is just the beginning, there are lot more to come including, code level line by line debugging, alerting, code level outbound connections tracing etc. Stay tuned!!