Nms-aws: Difference between revisions
Jump to navigation
Jump to search
(Created page with "=== Notes on todo for AWS support === Category:NMS") |
|||
| Line 1: | Line 1: | ||
=== Notes on todo for AWS support === | === Notes on todo for AWS support === | ||
Going to have to figure out how to reliably support cloud infra. This is going to be somewhat painful as we cannot guarantee access to a given account URI or internal infrastructure. | |||
=== todo === | |||
* Investigate if there is a complete GOOD class for AWS that has good maintenance. | |||
* See if it is possible to link things like cloudwatch into the NMS even if it is outside the VPC. | |||
* EXPECT IAM policy to have minimal access. Gracefully monitor whatever is allowed by policy. | |||
* think of possible support via different key/secrets inside the same VPC | |||
* Investigate SQS eventing into API. | |||
* leverage raw stats from AWS whenever possible to graph inside the application with links to source. This is going to be important as AWS gives skewed data sometimes. | |||
* to think about for exclusive AWS systems: tie to IAM policy? Is this possible? | |||
* Do NOT duplicate AWS functionality, link to it. AWS is truth for itself, use that fact. | |||
* Never code ANY writes into AWS. This is a monitoring system, not a fixit for errs found. That is potentially unsafe to allow an NMS to automate fixes | |||
Simple things like ec2 feel like low hanging fruit that can be more easily ingested. The assumption is going to be one of two types. | |||
# Internal daemonPoller and Event receiver that forwards to main API outside of the VPC (shim) | |||
# Entire application is inside the common VPC (full/local) | |||
Latest revision as of 15:09, 6 June 2023
Notes on todo for AWS support
Going to have to figure out how to reliably support cloud infra. This is going to be somewhat painful as we cannot guarantee access to a given account URI or internal infrastructure.
todo
- Investigate if there is a complete GOOD class for AWS that has good maintenance.
- See if it is possible to link things like cloudwatch into the NMS even if it is outside the VPC.
- EXPECT IAM policy to have minimal access. Gracefully monitor whatever is allowed by policy.
- think of possible support via different key/secrets inside the same VPC
- Investigate SQS eventing into API.
- leverage raw stats from AWS whenever possible to graph inside the application with links to source. This is going to be important as AWS gives skewed data sometimes.
- to think about for exclusive AWS systems: tie to IAM policy? Is this possible?
- Do NOT duplicate AWS functionality, link to it. AWS is truth for itself, use that fact.
- Never code ANY writes into AWS. This is a monitoring system, not a fixit for errs found. That is potentially unsafe to allow an NMS to automate fixes
Simple things like ec2 feel like low hanging fruit that can be more easily ingested. The assumption is going to be one of two types.
- Internal daemonPoller and Event receiver that forwards to main API outside of the VPC (shim)
- Entire application is inside the common VPC (full/local)