-
Notifications
You must be signed in to change notification settings - Fork 4
feat: support pulling from cloudwatch metrics #58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
variable "filters" { | ||
description = "List of filters." | ||
type = list(object({ | ||
namespace = string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The rationale here is that polling is a cost sensitive measure, and so the API should nudge people towards being specific. If you want a wildcard, you might as well configure a cloudwatch metrics stream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, all minor comments
This commit addresses nits uncovered in #58 which were also applicable to the snapshot module.
This commit addresses nits uncovered in #58 which were also applicable to the snapshot module.
This commit introduces a new submodule, `cloudwatch_metrics`. Similar to our API snapshot functionality, we set up a eventbridge rule that periodically triggers the lambda with a custom payload. This payload tells the lambda what metrics to scrape for. Callers of this module can configure metric collection through the `period`, `interval`, `delay` and `filters` variables. Users must provide a list of filters. Each filter must have a namespace, and an optional set of metric names and dimensions. Co-authored-by: Ben Drucker <bvdrucker@gmail.com>
This commit addresses nits uncovered in #58 which were also applicable to the snapshot module.
This commit addresses nits uncovered in #58 which were also applicable to the snapshot module.
This commit introduces a new submodule,
cloudwatch_metrics
. Similar to our API snapshot functionality, we set up a eventbridge rule that periodically triggers the lambda with a custom payload.This payload tells the lambda what metrics to scrape for. Callers of this module can configure metric collection through the
period
,interval
,delay
andfilters
variables.Users must provide a list of filters. Each filter must have a namespace, and an optional set of metric names and dimensions.