docs: adds CloudWatch basics guide #26
Conversation
| title: Setting up CloudWatch Dashboards | ||
| description: How to set up a basic CloudWatch Dashboard | ||
| --- | ||
|
|
There was a problem hiding this comment.
This could probably be better with screenshots, but I don't want to expose any of our logs, and I think they'd be out of date pretty fast. The AWS docs linked have a good amount of screenshots.
catheraaine
force-pushed
the
catherine/cloudwatch-dashboards
branch
2 times, most recently
from
5d84b12 to
3476e6a
Compare
catheraaine
force-pushed
the
catherine/cloudwatch-dashboards
branch
from
3476e6a to
d6b5e01
Compare
|
|
||
| ## What is a CloudWatch Dashboard? | ||
|
|
||
| CloudWatch is an AWS service that collects metrics, logs, and events from the AWS services we use. For example, CCM can use CloudWatch to monitor traffic, check response time, and log user input from Amazon Connect. |
There was a problem hiding this comment.
Can we spell out CCM here? Future-us or new folks may not know what it stands for
| CloudWatch Dashboards are useful when you need to accomplish tasks such as: | ||
|
|
||
| - Monitor the health of your application | ||
| - Review metrics and logs across different services, e.g. Connect and Lex |
There was a problem hiding this comment.
| - Review metrics and logs across different services, e.g. Connect and Lex | |
| - Review metrics and logs across different services, e.g. [Connect](https://aws.amazon.com/connect/) and [Lex](https://aws.amazon.com/lex/) |
|
|
||
| ### Before you start | ||
|
|
||
| Before creating a dashboard, you have to have the right permissions enabled. At minimum, your AWS user account must have: |
There was a problem hiding this comment.
Can we add instructions on what to do if your AWS account does not have these permissions and where to check?
There was a problem hiding this comment.
I wonder if this might be something that needs to be done through a separate request (agency-specific or OIT) and not something we can do on our own. I think this permission would be associated to our role that we login to an account with (ie: AWSAdministratorAccess). If we are given limited access to an AWS account, it is likely that will include Cloudwatch but not certainly. If we want to include general instructions for how to check: login to AWS console -> IAM -> Policies -> select your login access role -> under "Permissions" search "Cloudwatch" -> check read/write list for below listed permissions. I think it's possible that IAM would be restricted and one could not check if this permission exists for their access role (therefore outside request).
|
|
||
| #### 2. Add a widget | ||
|
|
||
| On the dashboard screen, click the (probably orange) **+** to add a widget. |
There was a problem hiding this comment.
| On the dashboard screen, click the (probably orange) **+** to add a widget. | |
| On the dashboard screen, click the plus sign to add a widget. |
|
|
||
| The default query is a good place to start. | ||
|
|
||
| After selecting your log group, run: |
There was a problem hiding this comment.
Is there a process to run the code? maybe just a "run" button? (apologies, I'm not familiar with the service)
There was a problem hiding this comment.
There should be a button (I think similar to the others, probably orange) that says "Run query". The default code below is auto-populated.
|
|
||
| ### Design dashboards around questions | ||
|
|
||
| Dashboards can be overwhelming quickly. Before getting too excited and adding a million widgets to your dashboard, talk with your team (or yourself) and determine the most important metrics to understand about your application. It can be a good idea to design dashboards around questions, rather than services. For example, CCM might ask, "What percentage of our users have their question(s) answered by our automated chat bot?" This dashboard could have widgets tracking the number of individuals calling the Tax question line, what questions they asked, how each question was assigned an answer, and how many callers said their reason for calling was resolved. |
There was a problem hiding this comment.
| Dashboards can be overwhelming quickly. Before getting too excited and adding a million widgets to your dashboard, talk with your team (or yourself) and determine the most important metrics to understand about your application. It can be a good idea to design dashboards around questions, rather than services. For example, CCM might ask, "What percentage of our users have their question(s) answered by our automated chat bot?" This dashboard could have widgets tracking the number of individuals calling the Tax question line, what questions they asked, how each question was assigned an answer, and how many callers said their reason for calling was resolved. | |
| Dashboards can be overwhelming quickly. Before getting too excited and adding a million widgets to your dashboard, talk with your team (or yourself) and determine the most important metrics to understand about your application. It can be a good idea to design dashboards around questions, rather than services. For example, you might ask, "What percentage of our users have their question(s) answered by our automated chat bot?" This dashboard could have widgets tracking the number of individuals calling the Tax question line, what questions they asked, how each question was assigned an answer, and how many callers said their reason for calling was resolved. |
|
|
||
| ### Create different dashboards for different purposes | ||
|
|
||
| If you come up with several questions it may be a good idea to create multiple dashboards, especially if each question has different stakeholder audiences. For example, our user question above is important to business and product. We may also decide to create a second, engineer-focused dashboard that tracks Lex response times and how many errors the system flagged. |
There was a problem hiding this comment.
| If you come up with several questions it may be a good idea to create multiple dashboards, especially if each question has different stakeholder audiences. For example, our user question above is important to business and product. We may also decide to create a second, engineer-focused dashboard that tracks Lex response times and how many errors the system flagged. | |
| If you come up with several questions it may be a good idea to create multiple dashboards, especially if each question has different stakeholder audiences. For example, our user question above is important to business and product. We may also decide to create a second, engineer-focused dashboard that tracks [Lex](https://aws.amazon.com/lex/) response times and how many errors the system flagged. |
There was a problem hiding this comment.
just being extra clear that Lex is an AWS service
|
|
||
| ### Time ranges | ||
|
|
||
| If no data is showing on your dashboard, the most likely reason is that there simply is no data for the selected time frame. AWS defaults to the last 3 hours. You may need to adjust the time frame to be much longer than that. |
There was a problem hiding this comment.
This is such a good callout. It seems so obvious but also can be something that throws one into a panic on first look.
LynnHerrick9
left a comment
LynnHerrick9
left a comment
There was a problem hiding this comment.
Looks great, Catherine! I got to this after Tim and he left some good suggestions. Nothing in addition from me.
catheraaine
force-pushed
the
catherine/cloudwatch-dashboards
branch
from
d6b5e01 to
3614f6b
Compare
catheraaine
dismissed
timwright12’s stale review
stale, thanks for the feedback!
3 participants
Creates a guide for adding a very simple CloudWatch dashboard, along with some common blunders one might encounter.