Navigation Menu

Skip to content
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

As an RDS broker user, I want to get alerts around my database #534

Closed
afeld opened this issue Dec 1, 2016 · 4 comments
Closed

As an RDS broker user, I want to get alerts around my database #534

afeld opened this issue Dec 1, 2016 · 4 comments
Labels
operations Platform operations, development, and support issues

Comments

@afeld
Copy link
Contributor

afeld commented Dec 1, 2016

We should give users an option to (and/or enable by default?) alerts around high levels or spikes in:

  • Memory
  • CPU

@LindsayYoung Anything I'm missing?

@afeld afeld added the operations Platform operations, development, and support issues label Dec 1, 2016
@LindsayYoung
Copy link
Contributor

free space

@mogul
Copy link
Contributor

mogul commented Jan 10, 2017

The current quarter's direction is to give you the ability to get the metrics out, but then leave who/how to alert up to you (where OpenDuty runs easily on Heroku, and is therefore highly likely to also run on cloud.gov...)

@jmcarp
Copy link
Contributor

jmcarp commented Jan 24, 2017

I took another look at this, and I think it's going to be more work than expected to expose metrics. Cloudwatch metrics don't expose resource-level permissions, so we can't make iam policies that grant the user permissions to get metrics from a particular rds instance--we'd have to run a web service that proxies the aws api with a custom auth layer. We could also set the broker up to allow users to configure arbitrary alerts via sns, but that still wouldn't expose the actual metric values.

Thoughts @mogul? Copying @cnelson because we might have a similar issue with cloudfront and federalist.

@mogul mogul added Backlog and removed Ready labels Jan 25, 2017
@mogul mogul removed Backlog labels Feb 2, 2017
@mogul
Copy link
Contributor

mogul commented Jul 7, 2019

Not doing this any time soon.

@mogul mogul closed this as completed Jul 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
operations Platform operations, development, and support issues
Projects
None yet
Development

No branches or pull requests

5 participants