Follows-up from {T180766}, and potentially depends on some of T158837.
Specifically, we should:
* [ ] Set up the Redis instance for stack logs (in prod on mwlog1001).
* [ ] Set up the deamon that writes from Redis to log files on disk (in prod on mwlog1001).
* [ ] Set up the deamon that generates SVG flame graphs from stack log files on disk (in prod on mwlog1001).
* [ ] Set up the Apache that serves the flame graphs and stack logs (in prod on mwlog1001).
* [ ] Set up a public proxy to expose that Apache (either custom for beta, or by deploying the performance-site to Beta Cluster, the latter would be nice).
Doing this would help with {T176916}.
For T176916, I'd like to set up a copy of the flame graph pipeline for xhprof-sampled data. This way we can keep them separate from the existing one. Because 1) to avoid corruption and duplication due to different data sources (Xenon vs xhprof) that also have different sampler intervals, and 2) To be able to compare them side by side, and 3) To be able to ramp up the new one slowly without being lost in the noise.
We could do all that directly in production, but I'm proposing we take this opportunity to clean up the flamegraph stack in production. Part of it currently runs on hardware not really intended for its purpose. Once that is done, it should be easy to recreate the setup in Beta Cluster by using the same puppet profiles. Probably by adding a webperf VM to the Beta Cluster.
That would also give us the ability to try out puppet-level changes (e.g. to change Apache configuration or otherewise) in Beta before production.
This should also make it easier to experiment with the xhprof-based samplings, which we could leave running in Beta for a while to compare results side-by-side.