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