Add updated documentation for debugging data stoppage alerts.

tools/perf/docs/perf_regression_sheriffing.md

 # Perf Regression Sheriffing (go/perfregression-sheriff)
 
 The perf regression sheriff tracks performance regressions in Chrome's
 continuous integration tests. Note that a [new rotation](perf_bot_sheriffing.md)
 has been created to ensure the builds and tests stay green, so the perf
 regression sheriff role is now entirely focused on performance.
 
 **[Rotation calendar](https://calendar.google.com/calendar/embed?src=google.com_2fpmo740pd1unrui9d7cgpbg2k%40group.calendar.google.com)**
 
 ## Key Responsibilities
 
  * [Triage Regressions on the Perf Dashboard](#Triage-Regressions-on-the-Perf-Dashboard)
  * [Triaging Data Stoppage Alerts](#Triaging-Data-Stoppage-Alerts)
  * [Follow up on Performance Regressions](#Follow-up-on-Performance-Regressions)
  * [Give Feedback on our Infrastructure](#Give-Feedback-on-our-Infrastructure)
 
 ## Triage Regressions on the Perf Dashboard
 
 Open the perf dashboard [alerts page](https://chromeperf.appspot.com/alerts).
 
 In the upper right corner, **sign in with your Chromium account**. Signing in is
 important in order to be able to kick off bisect jobs, and see data from
 internal waterfalls.
 
 Pick up **Chromium Perf Sheriff** from "Select an item ▼" drop down menu. There
 are two tables of alerts that may be shown:
 
- * "Performance Alerts", which you should triage, and
- * "Data Stoppage Alerts", which you can ignore.
+ * "Performance Alerts"
+ * "Data Stoppage Alerts"
 
 For either type of alert, if there are no currently pending alerts, then the
 table won't be shown.
 
 The list can be sorted by clicking on the column header. When you click on the
 checkbox next to an alert, all the other alerts that occurred in the same
 revision range will be highlighted.
 
 Check the boxes next to the alerts you want to take a look at, and click the
 "Graph" button. You'll be taken to a page with a table at the top listing all
@@ skipping 39 matching lines @@
    to see a broader revision range feel free to click on the alert on that graph
    and kick off a bisect for it. There should be capacity to kick off as many
    bisects as you feel are necessary to investigate; [give feedback](#feedback)
    below if you feel that is not the case.
 
 ## Triaging Data Stoppage Alerts
 
 Data stoppage alerts are listed on the
 [perf dashboard alerts page](https://chromeperf.appspot.com/alerts). Whenever
 the dashboard is monitoring a metric, and that metric stops sending data, an
-alert is fired. Some of these alerts are expected:
-
-   * When a telemetry benchmark is disabled, we get a data stoppage alert.
-     Check the [code for the benchmark](https://code.google.com/p/chromium/codesearch#chromium/src/tools/perf/benchmarks/)
-     to see if it has been disabled, and if so associate the alert with the
-     bug for the disable.
-   * When a bot has been turned down. These should be announced to
-     perf-sheriffs@chromium.org, but if you can't find the bot on
-     [the waterfall](https://uberchromegw.corp.google.com/i/chromium.perf/) and
-     you didn't see the announcement, double check in the speed infra chat.
-     Ideally these will be associated with the bug for the bot turndown, but
-     it's okay to mark them invalid if you can't find the bug.
-     You can check the
-     [recipe](https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/chromium_tests/chromium_perf.py)
-     to find a corresponding bot name for waterfall with one for dashboard.
-
-If there doesn't seem to be a valid reason for the alert, file a bug on it
-using the perf dashboard, and cc [the owner](http://go/perf-owners). Then do
-some diagnosis:
-
-   * Look at the perf dashboard graph to see the last revision we got data for,
-     and note that in the bug. Click on the `buildbot stdio` link in the tooltip
-     to find the buildbot status page for the last good build, and increment
-     the build number to get the first build with no data, and note that in the
-     bug as well. Check for any changes to the test in the revision range.
-   * Go to the buildbot status page of the bot which should be running the test.
-     Is it running the test? If not, note that in the bug.
-   * If it is running the test and the test is failing, diagnose as a test
-     failure.
-   * If it is running the test and the test is passing, check the `json.output`
-     link on the buildbot status page for the test. This is the data the test
-     sent to the perf dashboard. Are there null values? Sometimes it lists a
-     reason as well. Please put your finding in the bug.
+alert is fired. See
+[triaging data stoppage alerts](triaging_data_stoppage_alerts.md) for more
+details.
 
 ## Follow up on Performance Regressions
 
 During your shift, you should try to follow up on each of the bugs you filed.
 Once you've triaged all the alerts, check to see if the bisects have come back,
 or if they failed. If the results came back, and a culprit was found, follow up
 with the CL author. If the bisects failed to update the bug with results, please
 file a bug on it (see [feedback](#feedback) links below).
 
 Also during your shift, please spend any spare time driving down bugs from the
@@ skipping 33 matching lines @@
   [go/bad-bisects](https://docs.google.com/spreadsheets/d/13PYIlRGE8eZzsrSocA3SR2LEHdzc8n9ORUoOE2vtO6I/edit#gid=0).
   The team triages these regularly. If you spot a really clear bug (bisect
   job red, bugs not being updated with bisect results) please file it in
   crbug with component `Tests>AutoBisect`. If a bisect problem is blocking a
   perf regression bug triage, **please file a new bug with component
   `Tests>AutoBisect` and block the regression bug on the bisect bug**. This
   makes it much easier for the team to triage, dupe, and close bugs on the
   infrastructure without affecting the state of the perf regression bugs.
 * **Noisy Tests**: Please file a bug in crbug with component `Tests>Telemetry`
   and [cc the owner](http://go/perf-owners).