Telemetry/Reboot: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* Ability to process 10x incoming packet rates of metrics telemetry infrastructure on a single AWS instance: 2400req/s with 30K HTTP POST packets. Fall | * Ability to process 10x incoming packet rates of metrics telemetry infrastructure on a single AWS instance: 2400req/s with 30K HTTP POST packets. Fall | ||
* Server should be bandwidth-limited, not CPU. | * Server should be bandwidth-limited, not CPU. | ||
* Server should make data available for map/reduce immediately. Fallback goal: 5min latency | * Server should make data available for map/reduce immediately. Fallback goal: 5min latency. In Q4 we'd like to use something like heka to make dashboards use live data(0min lag). | ||
Server Milestones: | Server Milestones: | ||
Revision as of 21:34, 20 August 2013
Goal: Fast, Robust server & frontend operational by Sep 31st able to accept and graph telemetry data. This means that as of Oct 1 http://metrics.mozilla.com/ will stop updating. Metrics should be able to retire telemetry portion of mango cluster in October.
Server requirements:
- Ability to process 10x incoming packet rates of metrics telemetry infrastructure on a single AWS instance: 2400req/s with 30K HTTP POST packets. Fall
- Server should be bandwidth-limited, not CPU.
- Server should make data available for map/reduce immediately. Fallback goal: 5min latency. In Q4 we'd like to use something like heka to make dashboards use live data(0min lag).
Server Milestones:
- Sep 2: Ability temporarily(1 hour?) point telemetry dns at AWS, forwarding telemetry to metrics cluster. Ideally we'd be able to do this at bouncer level so no changes are needed to accomplish forwarding
- Sep 16: ^ should be feeding both servers (metrics and AWS) until cutover date.
Dashboard Milestones
- Original etherpad https://etherpad.mozilla.org/telemetry-reboot