error and metrics alerting. In order to do that you must:
Managing errors can be a real pain in the ass sometimes, excuse the expression. To relieve the pain, Dashbird is grouping together all the similar errors for a certain Lambda. Nobody wants to deal with 50k errors separately, am I right?
There are in total of three error states (OPEN, RESOLVED, MUTED) where the error can sit. Every time a new error occurs it will be in the OPEN state. After fixing the error, be sure to mark it RESOLVED. Otherwise you will not be notified the next time when that error occurs.
You can resolve errors from the top right corner of the errors page and view resolved errors under the “RESOLVED” tab.
If an error is unimportant for you, you can mute notifications for it and discard it from the active errors list to reduce clutter.
It is always a good practice to have separate AWS accounts for different environments. Mostly it is because of security, development speed, billing etc. If you have separate accoutns – great, you can onboard all of them to Dashbird by using Organizations.
However, if haven’t done it or you want to separate your microservices, you can do it by grouping together Lambda functions under the Projects view. This will allow you to better monitor, analyze and debug your functions. Projects can also be targets to error or metrics alerting conditions, so you will only track what is necessary. Here’s a short guide how to set up your projects.
At Dashbird we release new features very often and therefore some of the most important things might get unnoticed. We try to notify all the important updates by newsletter, but feel free to check out our blog and docs from time to time for the latest information.
You can sign up for a Dashbird account here. If you have any questions just book a call with me and I can help you set up your account for success.
Failure detection, analytics and visibility for serverless applications in under 5 minutes.