Adding CloudWatch post
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful

This commit is contained in:
2022-11-12 08:21:44 -05:00
parent 067b09a996
commit 84d8d80d9b

View File

@@ -0,0 +1,54 @@
+++
title = "Structed and passively collected metrics via AWS CloudWatch"
date = "2022-11-12"
+++
AWS is a vast and sprawling set of services. It can be hard to find the hidden
gems like this one so I wanted to point this one out.
Structured metrics are very helpful to monitoring the health and function of an
software system.
- Do you want to know how long a particular transaction typically takes?
- How fast your database queries are?
- How long external APIs take to respond?
- Fire an alert when a particular function on the site happens too many times? Or too few times?
...plus a million other things specific to whatever system you're working on.
There are a lot of great tools for doing this and one that you might not know
about is AWS CloudWatch Metric Filters. If you're already on AWS then you
should consider these because it requires only that your application logs to CloudWatch.
If you're on ECS then the
[awslogs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html)
log driver for Docker gets you that nearly for free. By "free" I mean that your
application itself can have *zero* dependencies on AWS services and not require
any AWS credentials or libraries to start pumping out metrics that you can
visualize, alert on and record over time.
The [AWS
docs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
themselves offer the canonical reference for configuring these so I won't go
into detail here.
However, the gist is that for a log filter you define the following properties
- A filter pattern for extracting a discrete metric value out of a log entry
- A metric name to store the value in
- An optional dimension for sub-classifying the value
- And finally a log group to extract the metric values from
After that you just run the application and as the logs roll in the metric
values get pumped out. Then you can [define alarms for
alerting](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)
on them, [graph
them](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html),
[define autoscaling
rules](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html#policy-creating-alarm-console)
from them and more.
To conclude - AWS is big and hairy. While there are benefits to staying
platform agnostic, some AWS services don't require much or any coupling of your
application code to take advantage of. Cloudwatch Metrics is one of those
services and you can get a lot of value out of it with not much effort.