Just starting out with Dashbird? Great, you are in the right place.
I’ve been speaking with hundreds of our new users in the past couple for months about their experience with Dashbird. I must say the feedback has been incredible so far. However, there are a few things I’ve noticed that our users haven’t yet taken advantage of within the platform. For a better success, let me point them out to you.
If you haven’t tried out Dashbird yet and would like to follow along, feel free to try Dashbird out yourself – in the worst case scenario you will end up finding errors you didn’t have a clue of. Set up is an easy 2-minute process without any code changes.
Confusion around the alerting
- First set up the notification channels under Settings -> Organization -> Notifications (tutorial). We currently support email and Slack notifications.
- For error alerting, go to Errors –> Policies add a new policy by clicking + ADD. Be sure to add a notification channel you set up in the previous stage. Under conditions you can modify what kind of alerts (CRASH, TIMEOUT, OUT OF MEMORY, CONFIGURATION ERROR, EARLY EXIT) you would like to receive. Also, you can choose if you like to receive an alert for a certain function, project or all of your stack (detailed instructions).
- For metrics alerting, go to Alerting –> Polices. Similarly, to pervious step, add a new policy and set up the notification channels. You can choose to open a new incident (get alerted) per policy, condition or a certain target. There are many ways to configure the conditions and every company has different needs, but for better success we have pointed out the best practices for metric alerts that you can follow.
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.
“Error handling is for sure one of the most interesting things about Dashbird. Those who haven’t checked it out, are missing out!” - Hendry Sadrak, CTO at Modash, a database for finding instagram influencers.
Managing environments and microservices
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.