We are powering the workplaces of tomorrow! deskbird is the simplest and most efficient workplace management app for hybrid companies. Employees can see who is in the office, schedule their office and work-from-home days, and book desks in 2 clicks only. With a fast and intuitive user experience and a quick and reliable onboarding process, deskbird is the first workplace management system built around users, not buildings. That's why we value the privacy of our users with state-of-the-art encryption software. We also offer full integrations (e.g., with MS Teams), GDPR compliance, and numerous data protection configuration possibilities. Workplace managers have a birds-eye view of statistics like office occupancy and consumption at their fingertips, helping them to create a flexible workplace experience that employees love. We are one of Europe's fastest-growing SaaS startups, helping people and organizations to reach their full potential with our flexible workplace solution. We recently closed our funding round at $6.5M(September 2022). Wefox, Vitra, FlatexDEGIRO, Knauf, and many more trust us to keep their employees happy and productive with our highly-rated app. Discover more about our products and book a free demo on deskbird.com.

deskbird

Being a developer is awesome. Writing code, solving problems, and thinking of ingenious solutions for complicated algorithms is what we live for. But, the grass is not always so green on this side of the fence. Sooner or later, you need to get your hands dirty and deploy the app you worked so hard on. Deployments are not always easy. To be blunt, they can be challenging and time-consuming. That's what we'll solve in this tutorial. Goals Today you'll learn how to deploy a Node.js application to with the help of . AWS Lambda the Serverless Framework The walkthrough will also cover a real-life scenario of deploying a production version of your application, with environment variables, , and, of course, ; Oh, how I love seeing nice stack traces! proper monitoring easy debugging Prerequisites This tutorial will need you to have a few simple things set up already. Don't worry, it won't be long and will cover just the basics. AWS has 12 months of free tiers and plenty of lifetime free tiers, so don't worry about breaking the bank. : AWS account Here's a quick reference for making sure you have them installed. : Node.js and npm installed Check this out for an excellent reference and follow steps 1--3. : Serverless Framework installed This will give us the required overview to see what's happening to our app. : Dashbird account Ready? Let's go! . For copyable code snippets, see the original article What's AWS Lambda? AWS Lambda is a pay-as-you-go serverless compute service. Well, you just deploy your source code to AWS, and they handle the rest. Amazing! No need to fiddle with servers, ssh connections, Linux, or Vim. But, want to know what's even better? It scales automatically and has no downtime. I'll let that sink in... Which means what now? The technical definition for AWS Lambda would be a Function as a Service. You deploy some code; it gets invoked, processes some input, and returns a value. Simple! Hold up a sec. We need to mention a crucial fact. All lambda functions are stateless, meaning they cannot store persistent data. And, if I just said Function as a Service, how do we deploy a whole Node.js application to AWS Lambda? How Does It Work? When you think about it, it's not that complicated. A single lambda function is essentially just a tiny Node.js runtime environment. You can run whatever you want in there. That's what we'll do, package up a Node.js app and send it off to AWS Lambda. Sneaky. What Will We Deploy? The code we'll be deploying is just seven lines long to make this example as simple as possible. However, it could be as large as any Node.js application you have in production, and it would all work like a charm. Intriguing... How Do We Deploy It? In comes the Serverless Framework like a horse riding a white knight! Hold up; I may have that backward. Anyhow, this excellent framework enables us to both develop our apps locally, just like we're used to, but also deploy them with a straightforward command. Hmm... tell me more. Let's Get Coding! First thing's first. Open up your terminal; we need to install some packages. Yay, installing stuff, love it! 1. Install and Configure the Serverless Framework $ npm install -g serverless Prefix the command with if you're running this command on Linux. sudo Make sure to add your IAM User's public and secret key instead of the placeholders I specified above. The user needs programmatic access and admin permissions. . Here's the official guide in the AWS docs 2. Create the Boilerplate Code Let's create a new folder and give it a unique name. Jump over to your terminal and run the commands below. $ mkdir serverless-nodejs-app && cd serverless-nodejs-app Excellent! Now, what's left is to run the create command to generate some starter code for us. This is called a serverless service. $ sls create -t aws-nodejs -n serverless-nodejs-app Only one more step before opening a code editor. Installing Dependencies Like you can see in the code snippet above, we need to install a few modules first. Lucky for us, there are only two, and it's as simple as running one command. That's it! Let's open it up in a code editor and do some actual coding. Coding For Real Once you open up the code editor, you'll see three files. Ignoring the , let me explain what the is first, then I'll move on to the . The handler will hold all your app logic, all the code. In contrast, the is the configuration file for the resources you'll be creating on AWS. .gitignore file handler.js serverless.yml servereless.yml Go ahead and rename the to , to help us figure out what goes where. handler.js app.js Delete all the starter code and paste this code snippet into the file. app.js Seven lines of code? It looks familiar, right? Just like you're used to. That's it. Believe it or not, there's nothing more to it. Let's move on to the . serverless.yml Once again, delete all the boilerplate code and paste this in. Done! All that's left is to deploy it. Ready to Deploy! Switch back to the terminal window. By running one command, your app will be deployed. $ sls deploy The Serverless Framework will now wrap everything up into a nice bundle, create a CloudFormation file from the and shoot it off to AWS S3. Once the resources are created, and the code is deployed, you'll see an endpoint sent to you in the terminal. serverless.yml Open up the provided URL in a browser. You'll see that gets sent back to you. "Hello World!" Deploying to Production! This is great and all, but not ready for a production environment... yet. Worry not! You'll be surprised how simple it is to make it production-ready. Add a file for environment variables secrets.json For now, let's just add the in the . NODE_ENV secrets.json Add a reference for the in the secrets.json serverless.yml As simple as adding the secrets file, it's even easier to reference the file in the . serverless.yml Amazing, that's it! Delete the and folders from the service and run npm install again, but this time with the flag. node_modules .serverless --production $ npm install --- production Great! All that's left is to re-deploy the service, and you're set. $ sls deploy And this is what we end up with. I guess we're done? Not really. Having an app running in production just because you installed npm modules with doesn't cut it. To be able to sleep well at night, I need a bit more. Here's where proper system insight and monitoring tools come to play. --production Let me show you. How to Gain Insight Into Your System? The #1 problem with all serverless applications is their distributed nature. Plain and simple, it's impossibly hard to have an overview of all the things going on. Not to mention how hard it is to debug when something goes wrong. To calm my fears, I use . It's a simple monitoring tool that doesn't require me to change any code and has no overhead. So, no performance hits either. Nice! Dashbird Thankfully, they have sensible documentation, which makes the onboarding process a breeze. Go ahead and follow their . Don't forget to come back here, though. Quick Start guide Once you're done, all the requests will start piling in one by one, and you should see something like this. The function details will give you an overview of how the function behaved over time, so multiple invocations are aggregated here. If you click on a recent invocation at the bottom left, you will drill down to the invocation level of details that comes with tracing and logging data. Wrapping Up This was fun! Lambda is awesome! When combined with HTTP event triggers such as , development tools like the Serverless Framework, and observability tools such as , things just become so easy. API Gateway Dashbird This simple API example we coded above is just a proof of concept. But you can see the point. It gives you a starting point from where you can create awesome production apps! If you missed any of the steps above, . here's the repository with all the code First Published here Further reading: How to check NFT supply with AWS Lambda How to test serverless applications Top 6 AWS Lambda monitoring tools How to solve serverless cold starts AWS Lambda Node.js errors and exceptions

Go Serverless with AWS Lambda, Node.js and Dashbird

In the 21st century, it’s quite easy to manipulate machines and computers. Our worries are no longer if something is doable, but if something can be perfected. Therefore, we mostly search for new ideas and ways to make our work impeccable. For example, if you’re using a particular software and you realize that the software is excellent, but it could be better in some ways that would allow you to work even faster, you’ll explore the alternatives. There are all kinds to choose from, and you will search for the one that is most suitable for your own needs. Every one of them has some perks of their own, and in others, you’ll notice some faults. In this article, we’ll make a brief introduction, and we’ll also talk about the differences between CloudWatch alerts vs. Dashbird alerts. Which one is better and why? What is AWS CloudWatch Used For? is built for system operators, site reliability engineers (SRE), IT managers, and developers. CloudWatch allows you to monitor your applications via data access and insights it provides. It can also recognize, understand and respond to all changes happening throughout the entire system. AWS CloudWatch CloudWatch is also collecting monitoring and operational data through metrics, events, and logs which further provides you with a unique view over the AWS resources, services, and apps that run on AWS, as well as in the localized servers. CloudWatch enables you to set alarms (or alerts), troubleshoot for issues, and discover the insights for application optimization which will ensure that the application runs smooth. AWS CloudWatch Alerts Explained A CloudWatch alert (a.k.a. alarm) can watch over a single CloudWatch metric or even a result of math expression found in CloudWatch metrics. Alerts will perform single or multiple actions based on the value of metric or expression which is relative to a threshold over a number of time periods. Adding alarms to AWS CloudWatch dashboard is enabled and that way you’ll be able to monitor them visually. There are three alarm states: – meaning that the expression or metric is found inside the already defined threshold; OK – implies that the expression or metric are located outside of the specified threshold; ALARM – this alert is shown when the alarm has already started but the metric is not available, or there’s not enough data for the metric to realize in which state the alarm is. INSUFFICIENT_DATA When creating an alarm, you are able to specify three settings that will allow CloudWatch to evaluate when to change the alarm state: – will enable you to evaluate the time length of metric or expression in order to create an individual data point for an alarm; Period – is the number of the recent data points you need to evaluate to be able to determine the state of the alarm; Evaluation Period – is the number of data points in the evaluation period that must be breached, so it’s causing the alarm to go to the ALARM state. These breaching data points must all be within the last number of data points which is equal to the Evaluation Period. Datapoints to Alarm There are a lot of features that apply to all AWS CloudWatch alarms, and we’ll go through some of them. For example, the number of evaluation periods for an alarm if multiplied by the length of every evaluation period can’t surpass the one-day limit. Another feature worth mentioning is that ASCII characters must be included in alarm naming. You are also able to create 5,000 alarms within every region per a single AWS account. Metrics CloudWatch gathers basic metrics, which further allows you to how the entire system performs. The collected metrics for Lambda functions are latency, invocations, errors, and concurrency. Since the chances of you checking the metrics precisely at the same time when something goes wrong are pretty slim, it would be wise to configure alarms upfront (more on this and best practices below). Do this in case an unexpected event meets a condition or threshold so the alarm could notify you in time. monitor How to Set Up Your Metric Alarms on AWS CloudWatch? You should first , but only if the predefined condition is fully met. The SNS trigger will then invoke a Lambda function to take action. This action will send notifications so you can further investigate the issue. configure a CloudWatch metric alarm to trigger an SNS topic Setting Up Metric Alerting on AWS (Best Practices) Can you recognize the optimal time to ? The answer depends on whether you’d like to receive alerts only in cases that require your immediate attention or not. Even if you set them up to alert you often, responding to each and every alert is not feasible. It means that it won’t be long before you miss a crucial alert, which is bound to happen either because of the noise or because you began ignoring alerts entirely. configure a metric alarm Try to understand all of it this way: Do you think it’s okay if 1% of all requests fail due to a single function? Is it of vital importance that all requests take no longer than 1 second? In these cases, you’d probably want to know if your Lambda is reaching a (account-wide). All these settings are completely individual for each application, and it usually takes some time and iterations before you can get it to an acceptable level. concurrency limit Another thing you should think about is configuring naturally preventive alerts. These alerts will trigger even when nothing has failed yet, but it might happen soon. A good example will be if a Lambda function is close to a timeout or even closer to fill its memory capacity – remember that CloudWatch attains metrics for invocation counts, latency, memory usage, and failures by default. High-Resolution Metric Alarms If you set the alarm on a high-resolution metric, you’re allowed to specify a high-resolution alarm in specific time groups (10 or 30 seconds). Moreover, you can set up a standard 60-second alarm multiple times. It’s also essential to know that high-resolution alarms are charged at a higher rate so be sure to do a cost analysis if that could be a potential issue. Standard AWS CloudWatch Alerts Features CloudWatch alarms have numerous features, and the ones listed below are common and apply to all alarms: Each AWS account can create up to 5,000 alarms for each Region. You should use the CloudWatch console if you wish to update an existing alarm or create a new one. Use the command put-metric-alarm in AWS CLI or utilize an API action called PutMetricAlarm that’s also available. Only ASCII characters are allowed in alarm name fields. You can either enlist some or even all of the alarms that are currently configured. You can also list any alarms within a particular state by utilizing the CW console by looking for an API action DescribeAlarms. Alternatively, look in for the command describe-alarms. AWS CLI You can also enable or disable alarms via the CloudWatch console. To do so requires you to look for API actions EnableAlarmActions and DisableAlarmActions. As an alternative, you can look for the following commands in AWS CLI: enable-alarm-actions and disable-alarm-actions. Set the alarm to any state to test it by utilizing either an API action: SetAlarmState, or by utilizing command in AWS CLI: set-alarm-state. Remember that when the next alarm comparison happens, this temporary state change will be over. It’s possible to create a custom metric alarm even before making this particular custom metric. You have to include all of the custom metric’s dimensions along with the metric name and metric namespace within the alarm definition to make it valid. You can do this via a command in the AWS CLI: put-metric-alarm, or via API action: PutMetricAlarm. Viewing an alarm’s history is possible via CloudWatch console as it saves alarm history for 14 days. You can either use a command in AWS CLI: describe-alarm-history, or an API action: DescribeAlarmHistory within the console. You should know that every state transition has its unique mark in the form of a timestamp. Make note that your history might show even more than one notification for a single state change. However, that’s quite rare. Also, you can confirm all unique state changes as the timestamp enables you to do so. The evaluation periods’ quantity for each alarm multiplied by the length of each and every evaluation period can’t exceed 24 hours. Dashbird Alarms and Notifications Explained Dashbird’s instant alerting system will notify you if any issue shows up within any part of your application. Issues such as crashes, , runtime errors, timeouts, configuration errors, and early exits. Its system offers messages and realistic logs that humans can easily read and understand, which saves you and your company meaningful debugging time. Dashbird monitors your application and is able to detect all kinds of errors in various runtime environments. cold starts The Events page does everything an observability tool should – showcase all errors occurring within your system. With Dashbird, you can customize which events to track and how you want to get notified. Everything mentioned above works for programming languages supported by AWS Lambda, including Node.js, Python, Java, and C#. All the required data to successfully go through troubleshooting events and resolve any app issues are entirely at your disposal. A human-friendly interface will present you with any previous occurrences, stack traces, etc. Logs and trends for every error or problem are also available. You can use a “more info” button for every single error you face, and that way, you’ll see the error page with all the needed info for debugging the current issue. Configuring an Alert Policy (Alarms) with Dashbird To configure an alert policy, simply visit Events from the left navigation menu and click on the Settings tab on the Events panel. From here, click on Alarms and click + ADD: Dashbird gives you complete control over Alarms as it allows you to choose which error reports you should receive. You’re required to set and configure the Alarms rules. That way, you’re adding a new policy to the list, and from there, you can start configuring how you want to be notified of Alarms. Defining Alarms for any ‘error overall functions’ is possible, but you can also set the system to alert you when a specific microservice or function experiences invocation timeouts. Setting Up Notifications Proactive alerts are another one of Dashbird’s features. You could set up an email notification system or seamlessly integrate it with Slack. We also support SNS and webhooks. All policies require at least one alert condition along with one notification channel. An alert state consists of different functions and error conditions, while a notification channel can either be an email address or even Slack. The Best Ways to Handle Alerts Consider alerting as an ongoing process. Therefore, we at Dashbird recommend you to test different policies. These are some basic principles and suggestions on how to handle alerts when they emerge: You should add new Alarms whenever you need them, but you should also mute or delete unnecessary ones so you would avoid alarm fatigue. Even if you think production Lambdas will never fail, you should set alerts for them too, as unexpected circumstances tend to happen from time to time. If you’ve fixed alerts within the code, it’s always mandatory to resolve them as well. By doing so, if the same problem happens again, you’ll receive a new notification. Conclusion Both CloudWatch and Dashbird have their pros and cons, and we’ll wrap up here after mentioning a few. While Cloudwatch is mostly an excellent choice for users who are already inside the AWS ecosystem, it’s not all that great for the ones who aren’t, and they should find a simpler solution. The alerting options for CloudWatch are not as boundless since they’re available with third-party services. Moreover, CloudWatch doesn’t offer pre-configured alerts. It would be best if you create custom alerts by yourself, which means you must be very familiar with how everything works in order to create them properly. On the other hand, Dashbird’s alert notification system is automated and instant, which undoubtedly provides you comfort and ease if something happens within your application. During the past three years, we’ve heavily invested in the new Dashbird app interface and building the next stages of our platform. We’ve expanded our offer, and it now includes services like API Gateway, Step-Functions, DynamoDB, Kinesis, ECS, and SQS, and many more to come soon.

Setting Up AWS CloudWatch Alerts (vs Dashbird Alerts) To Monitor Your Applications

The serverless space is relatively new and rapidly changing and improving (just look at the monster list of launches and updates from re:Invent). To keep up and maintain top efficiency, so should serverless developers. This is our round-up of all the enhanced serverless observability feature releases Dashbird launched in 2020 that will help serverless users troubleshoot and scale better in 2021. So here we go! Inventory Having previously exclusively served AWS Lambda, earlier this year, Dashbird added more AWS services to our roster for serverless monitoring, observability, and optimization opportunities. The Inventory list includes: AWS SQS AWS DynamoDB AWS API Gateway AWS ECS AWS Kinesis AWS Step Functions The addition of these instrumental services and resources to the Dashbird monitoring platform gives you even greater autonomy and understanding of your Serverless infrastructure. With the ability to drill down into the details, set up alerts, and watch for trends and patterns, Dashbird offers . All without any code or architectural changes. You just have to deploy CloudFormation template to your AWS, and can start receiving pre-configured automated alerts and working with your data immediately. one of the fullest Serverless observability platforms available today Well-Architected and Best-Practice Insights Dashbird is constantly running users’ infrastructure data through its WAF rule engines detecting anomalies and weaknesses within the architecture, and notifying the users of critical errors and/or when improvements should be made. Dashbird features a continuous rule engine for detecting and enforcing Serverless Well-Architected practices. This allows developers to build and operate complex Well-Architected serverless applications without compromising reliability over time and also be able to layer on complexity later on. Metric Alarms In addition to the Inventory, we also added the Metric Alarms feature. Its simplicity – choosing a metric important to you, setting its status to ‘critical’ or ‘warning’, and pointing to the relevant resources and the person this alarm should reach – , meaning alert fatigue and complex alarms can be a thing of the past. You can be confident that important information reaches the correct person in time! lets you cut through the noise Used in conjunction with Dashbird Insights Engine, Metric Alarm allows users to and to customize their infrastructure based on solid insight. gain greater assurance over SLAs/SLIs For example, here we have configured a critical alarm to be triggered when the queue has reached 10 or more items. This alarm helps detect situations like when the queue consumers cannot keep up with new messages in the queue – that is when messages arrive faster than they can be processed. So whenever that happens, Alex from our dev team gets notified in real-time via Slack (his preferred channel). Detailed Usage Report The Detailed Usage Report provides another element to the metrics and insights Dashbird already offers. Shown by; Usage by Region and by Type, Data Ingested by Region and by Lambda, and Lambda Invocation, it’s one step easier to . spot trends and patterns for better optimization For example, understanding the pattern of a well-used Lambda from this starting point, users can then look into its related billing and resource usage patterns to identify if savings can be made in either AWS or Dashbird. Notifications Channel & New Communication Channels Dashbird has now enabled alerts and alarms to be sent through AWS SNS and Webhooks, making automation and autoscaling even easier and more seamless. Out-of-the-box notifications can be set up, as can the customized ones. Understanding that each company’s workflow is different, the Notification Channel now makes it easier to point alerts to a specific team member or group for faster internal communication, acknowledgment, and remediation. Dashbird app got a shiny new look The new and improved Dashbird app’s main screen is designed to give you a quick overview of the most important events and metrics across your serverless environment. Jump in and check it out! Previously published at https://dashbird.io/blog/dashbird-feature-releases-2020/

Scale Your Serverless App with Dashbird's New Features

With AWS Lambda, we get scalability and resilience out-of-the-box. What’s more, AWS also provides built-in monitoring, logging and tracing support through CloudWatch and X-Ray. These built-in tools provide a good starting point but many developers eventually outgrow them as their serverless application becomes more complex. In this post, let’s take a serverless application and see how can help you debug the application. Dashbird Challenges with serverless observability When it comes to observability, serverless has introduced some interesting challenges. For so long, we have relied on the use of agents and daemons to collect metrics and logs. They run silently in the background, away from our critical paths where we are concerned with minimizing user-facing latencies. They collect, buffer and publish these observability data in batches to improve efficiency. As a practice, they are so deeply ingrained into how we monitor our applications, until now. When it comes to serverless, specifically with managed platforms such as AWS Lambda, there’s simply nowhere for us to install these agents! To collect metrics and logs as part of your function’s invocation would understandably add overhead to its invocation time. Since AWS is collecting logs from your function asynchronously already, and publishing them to CloudWatch Logs. A common workaround is to subscribe to these logs and perform post-processing on them. Indeed, that is how Dashbird collects data about your function’s execution. It subscribes the CloudWatch Logs log groups to a Kinesis stream and then processes the events from there. You can read about the advantages of this approach in . this article As our serverless applications become more complex, it’s important for us to be able to trace executions across multiple functions. As the demo app demonstrates, even a simple user transaction can span across multiple event sources as well as Lambda functions. The demo app Imagine you’re building a Twitter clone. One of the core features of the system is to distribute a user’s post to his followers’ feeds. To implement this feature, imagine we have two separate API endpoints: POST posts/create : to create a new post for the current user GET followers/{userId} : to fetch a user’s followers Each endpoint is handled by a separate Lambda function — and respectively. create-post get-followers When a user publishes a new post, the function would save the post in the DynamoDB table and also publish a event into a Kinesis stream. This event then triggers a function. This function would query the endpoint and then add the post to the followers’ feeds. The function would query the DynamoDB table to return the IDs of the user’s followers. create-post posts post-created distribute-post GET followers/{userId} get-followers followers For brevity sake I have omitted the logic for actually distributing the posts. So the overall architecture for our demo app looks like the following. To make things more interesting, each of the Lambda functions are hardwired to error or timeout based on a configurable probability. The source code for the demo app is , so feel free to try it out yourself. available on Github Introducing Dashbird Even with a simple serverless application like the one outlined above, we have quite a few functions to look after. Let’s see how we can use Dashbird to help us monitor this application and debug issues. As soon as I log in, I have a high level dashboard for my account. In addition to the data I get in the AWS Lambda console (see below), the Dashbird dashboard has two useful data points: Average memory utilization for the functions Cost for the Lambda invocations Next, in Dashbird’s Lambda console, I can see a high level summary of my functions and their activities over the last 24 hours. What I find very useful here is the fact that it highlights functions that have been idle for 10 days as inactive. As your serverless architecture expands and you end up with hundreds of functions, maintained by different teams, it’s very difficult to track which functions are no longer needed. Having redundant functions lying around is a security risk as they remain an attack surface that can be exploited. While this view alone cannot tell you definitively which functions are no longer used. Many functions are not run on a regular basis. Maybe they are part of a cron job that only runs once a month. Or maybe they are only used during disaster recovery scenarios. Nonetheless, being aware of which functions are inactive encourages teams to ask the question “Is this function still needed?”. From here, maybe better practices can emerge. For example, use tags to mark functions that are expected to be used sparingly so they are not flagged by these checks. If I navigate to one of the functions, then I have a function-centric view of invocation time, error, cost and memory utilization. In addition, I can also see a list of the recent invocations. What’s really useful here is that cold starts and retries are clearly labelled. When debugging live issues this lets me quickly narrow down the invocations that I need to pay attention to. Straight away, I can see that 3 of the invocations timed out after 6 seconds. What’s more, the original Kinesis event was retried 3 times and finally succeeded on the third retry. If I click on the “+” button next to an invocation then I can drill down to the invocation itself. Here I can see the logs and X-Ray trace for this invocation in one screen. This is great as it saves me from having to constantly jump between different AWS console. Debugging with Dashbird As mentioned before, the demo app is hardwired to error and timeout. And sure enough, when these failure cases happen, Dashbird’s built-in alerting kicks in and I promptly received emails notifying me that something went wrong. While this built-in alerting is great, I couldn’t see any settings to adjust the alert sensitivity. As I followed the links in the emails, to the function, then the failed invocation. Dashbird neatly groups the related invocations — the initial timeout, and the subsequent retries — together. I can quickly see that the failed Kinesis event was successfully processed on the 3rd retry. Dashbird also tracks the open issues in the Errors console. Now that I know the problem has resolved itself I can go ahead and resolve the error. Tailing function logs Another nice feature of Dashbird is that it’s able to tail the logs for multiple functions at the same time. For the demo app, I want to see the logs for both the and functions as I curl the endpoint. create-post distribute-post POST posts/create That way, I can see that the event was successfully published into the Kinesis stream, and was subsequently received by the function. distribute-post Conclusion Overall I was impressed with what Dashbird has to offer, and it’s clear that a lot of thought has gone into the product. It has many nice touches that makes debugging much easier. For example, grouping retries together, and integrating X-Ray traces and logs in one screen. These might seem like trivial niceties, but they can make a big difference under the high-pressure scenarios of dealing with a live issue. From what I have been able to see, I think Dashbird is a really great tool. The main thing missing for me is the ability to trace executions end-to-end. Personally, I’d really like to see the entire execution traced from the API call to create a post, all the way to the function performing a Query against the DynamoDB table. get-followers followers If you’re solely relying on the built-in AWS tools (CloudWatch, CloudWatch Logs, and X-Ray) then you should give Dashbird a try. Why not sign up for a free trial, and deploy the demo app to your environment so you can see how Dashbird can help you debug your serverless application? Originally published at dashbird.io on January 25, 2019.

DESKBIRD

deskbird.com

51-200 employees

Since 2020

COMPANY RANKING

DESKBIRD

EVERGREEN INDEX #2924

Representing this company? Click here to claim and customize this page!

deskbird WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

DESKBIRD

deskbird.com

51-200 employees

Since 2020

COMPANY RANKING

DESKBIRD

EVERGREEN INDEX #2924

RELATED COMPANIESRANK

STORIES ABOUT DESKBIRD

Representing this company? Click here to claim and customize this page!

deskbird WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!