Construct: Metrics, Dashboards and Alarms

[sam-goodwin]

We should integrate the LambdaRuntime with the embedded metrics library to output a base level of domain specific metrics for Command, Event, Policy, ReadModel.

Then we can generate dashboards and alarms on the infrastructure side, allowing for developers to customize the thresholds but providing sane defaults out of the box.

Our dashboards can also link to pre-populated cloud watch insights queries that search for event handler logs or even search a cloud watch log that includes all events in a BoundedContext.

• [x] instrument handlers with metrics for Commands and Policies
• [x] generate a dashboard with default metrics for a Bounded Context
• [ ] generate default alarm configuration for a bounded context and add to dashboard
• [ ] generate cloudwatch logs insights links for each of the lambda handlers and add them to the dashboard
• [ ] configure X-Ray for tracing commands, events and polices.

[sam-goodwin]

@davehimself any thoughts on best practices for out-of-the-box metrics?

[ryan-mars]

Should X-Ray be part of this?

[sam-goodwin]

Should X-Ray be part of this?

Good point, we should definitely leverage X-Ray. I don't have personal experience with X-Ray so will have to look into it.

[davehimself]

X-Ray should. From an ops perspective, tracing is the primary methodology for monitoring microservices and/or distributed architectures. Second to that, error rates and variances in "expected" $probe over $time (e.g., I/O writes per second).

I can envision such characteristics being captured during event storming.

[ryan-mars]

I can envision such characteristics being captured during event storming.

@davehimself What kinds of characteristics should be captured during event storming? Are you referring to business metrics or ops metrics?