π΅οΈAWS baseline observability
What do we get from the box with just a little configuration?
There's a lot written and discussed when it comes to observability vs monitoring. Let's go with Google's definition taken from DORA:
Monitoring is tooling or a technical solution that allows teams to watch and understand the state of their systems. Monitoring is based on gathering predefined sets of metrics or logs.
Observability is tooling or a technical solution that allows teams to actively debug their system. Observability is based on exploring properties and patterns not defined in advance.
β Source: Google: DevOps measurement: Monitoring and observability
Further, let's also add that monitoring classically is said to consist of the three "pillars" logs, metrics, and traces. In the cloud, these are all typically pretty easy to set up and we should aim to at least have these under control.
Of the three pillars, tracing is maybe the least well-understood. Do read Lightstep's good introductory article on tracing if you are interested in that area!
π― Example: Our serverless.yml
configuration enables X-Ray in the tracing
object. By default, CloudWatch log groups are created. Next, we add the serverless-plugin-aws-alerts
plugin to give us some basic metrics (throttles, etc.).
Read more about metrics with Serverless Framework here.
Taken together, these give us a very good level of baseline observability right out of the box.
Refer to the CloudWatch Logs Insights query syntax if you want to set up some nice log queries. Also note that a shortcoming with CloudWatch is that they don't seem ideal for cross-service logs, but they are just fine when it comes to checking on a specific service. This is the intention behind the coming Honeycomb addition below.
You can now see dashboards (metrics) in both the Lambda function view and CloudWatch (plus the logs themselves) and get the full X-Ray tracing. It's just as easy as that! Done deal.
Last updated