Adding CloudWatch post
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
This commit is contained in:
54
content/posts/cloudwatch-metric-filters.md
Normal file
54
content/posts/cloudwatch-metric-filters.md
Normal 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.
|
||||||
Reference in New Issue
Block a user