Difference between revisions of "MagnetoDB/specs/requestmetrics"
Charles Wang (talk | contribs) (MagnetoDB Request Metrics) |
Charles Wang (talk | contribs) m |
||
| Line 1: | Line 1: | ||
| + | === Request Real Time Metrics === | ||
| + | |||
| + | Real time request metrics including latency/count/etc. | ||
| + | |||
| + | === Specification status === | ||
| + | Draft | ||
| + | |||
| + | === Problem Description === | ||
To proactively address MagnetoDB operational issues, admin user needs real time visibility to request metrics data on each API node. Including: | To proactively address MagnetoDB operational issues, admin user needs real time visibility to request metrics data on each API node. Including: | ||
| − | number of requests | + | * number of requests |
| − | number of failures | + | * number of failures |
| − | number of errors | + | * number of errors |
| − | average latency | + | * average latency |
| − | median latency | + | * median latency |
| − | minimum latency | + | * minimum latency |
| − | maximum latency | + | * maximum latency |
| − | requests per second | + | * requests per second |
| − | distribution of request latency for each type of REST API call, such as "50%","66%","75%","80%","90%","95%","98%","99%","100%" | + | * distribution of request latency for each type of REST API call, such as "50%","66%","75%","80%","90%","95%","98%","99%","100%" |
| + | |||
| + | === Proposed Change === | ||
| + | |||
| + | ==== Alternatives ==== | ||
| + | |||
| + | ==== Security Impact ==== | ||
| + | |||
| + | * Does this change touch sensitive data such as tokens, keys, or user data? | ||
| + | * Does this change alter the API in a way that may impact security, such as a new way to access sensitive information or a new way to login? | ||
| + | * Does this change involve cryptography or hashing? | ||
| + | * Does this change require the use of sudo or any elevated privileges? | ||
| + | * Does this change involve using or parsing user-provided data? This could be directly at the API level or indirectly such as changes to a cache layer. | ||
| + | * Can this change enable a resource exhaustion attack, such as allowing a single API interaction to consume significant server resources? Some examples of this include launching subprocesses for each connection, or entity expansion attacks in XML. | ||
| + | |||
| + | ==== Notifications Impact ==== | ||
| + | |||
| + | ==== Other End User Impact ==== | ||
| + | |||
| + | ==== Performance Impact ==== | ||
| + | |||
| + | Performance impact should be minimal since if statsd is used. The metrics sent to statsd is through UDP. | ||
| + | |||
| + | ==== Other Deployer Impact ==== | ||
| + | |||
| + | A dependency in statsd will be introduced. | ||
| + | |||
| + | ==== Developer Impact ==== | ||
| + | |||
| + | |||
| + | ==== Implementation ==== | ||
| + | |||
| + | ===== Assignee(s) ===== | ||
| + | |||
| + | Charles Wang | ||
| + | |||
| + | ===== Work Items ===== | ||
| + | |||
| + | ===== Dependencies ===== | ||
| + | |||
| + | * statsd | ||
| + | |||
| + | ==== Documentation Impact ==== | ||
| + | |||
| + | ==== References ==== | ||
Revision as of 18:46, 18 November 2014
Request Real Time Metrics
Real time request metrics including latency/count/etc.
Specification status
Draft
Problem Description
To proactively address MagnetoDB operational issues, admin user needs real time visibility to request metrics data on each API node. Including:
- number of requests
- number of failures
- number of errors
- average latency
- median latency
- minimum latency
- maximum latency
- requests per second
- distribution of request latency for each type of REST API call, such as "50%","66%","75%","80%","90%","95%","98%","99%","100%"
Proposed Change
Alternatives
Security Impact
- Does this change touch sensitive data such as tokens, keys, or user data?
- Does this change alter the API in a way that may impact security, such as a new way to access sensitive information or a new way to login?
- Does this change involve cryptography or hashing?
- Does this change require the use of sudo or any elevated privileges?
- Does this change involve using or parsing user-provided data? This could be directly at the API level or indirectly such as changes to a cache layer.
- Can this change enable a resource exhaustion attack, such as allowing a single API interaction to consume significant server resources? Some examples of this include launching subprocesses for each connection, or entity expansion attacks in XML.
Notifications Impact
Other End User Impact
Performance Impact
Performance impact should be minimal since if statsd is used. The metrics sent to statsd is through UDP.
Other Deployer Impact
A dependency in statsd will be introduced.
Developer Impact
Implementation
Assignee(s)
Charles Wang
Work Items
Dependencies
- statsd
