Add "Useful Logs and Debugging Info" section to perf sheriff doc.

tools/perf/docs/perf_bot_sheriffing.md

 # Perf Bot Sheriffing
 
 The perf bot sheriff is responsible for keeping the bots on the chromium.perf
 waterfall up and running, and triaging performance test failures and flakes.
 
 **[Rotation calendar](https://calendar.google.com/calendar/embed?src=google.com_2fpmo740pd1unrui9d7cgpbg2k%40group.calendar.google.com)**
 
 ## Key Responsibilities
 
 *   [Handle Device and Bot Failures](#Handle-Device-and-Bot-Failures)
@@ skipping 188 matching lines @@
     *   The revision range the test occurred on.
     *   A list of all platforms the test fails on.
 2.  Disable the failing test if it is failing more than one out of five runs.
     (see below for instructions on telemetry and other types of tests). Make
     sure your disable cl includes a BUG= line with the bug from step 1 and the
     test owner is cc-ed on the bug.
 3.  After the disable CL lands, you can downgrade the priority to Pri-2 and
     ensure that the bug title reflects something like "Fix and re-enable
     testname".
 4.  Investigate the failure. Some tips for investigating:
-    *   When viewing buildbot step logs, **use the **<font color="blue">[stdout]</font>** link to view logs!**.
-        This will link to logdog logs which do not expire. Do not use or link
-        to the logs found through the <font color="blue">stdio</font> link
-        whenever possible as these logs will expire.
-    *   When investigating Android, look for the logcat which is uploaded to
-        Google Storage at the end of the run. logcat will contain much more
-        detailed Android device and crash info than will be found in
-        Telemetry logs.
     *   If it's a non flaky failure, indentify the first failed
         build so you can narrow down the range of CLs that causes the failure.
         You can use the
         [diagnose_test_failure](https://code.google.com/p/chromium/codesearch#chromium/src/tools/perf/diagnose_test_failure)
         script to automatically find the first failed build and the good & bad
         revisions (which can also be used for return code bisect).
     *   If you suspect a specific CL in the range, you can revert it locally and
         run the test on the
         [perf trybots](https://www.chromium.org/developers/telemetry/performance-try-bots).
     *   You can run a return code bisect to narrow down the culprit CL:
         1.  Open up the graph in the [perf dashboard](https://chromeperf.appspot.com/report)
             on one of the failing platforms.
         2.  Hover over a data point and click the "Bisect" button on the
             tooltip.
         3.  Type the **Bug ID** from step 1, the **Good Revision** the last
             commit pos data was received from, the **Bad Revision** the last
             commit pos and set **Bisect mode** to `return_code`.
     *   [Debugging telemetry failures](https://www.chromium.org/developers/telemetry/diagnosing-test-failures)
     *   On Android and Mac, you can view platform-level screenshots of the
         device screen for failing tests, links to which are printed in the logs.
         Often this will immediately reveal failure causes that are opaque from
         the logs alone. On other platforms, Devtools will produce tab
         screenshots as long as the tab did not crash.
 
+### Useful Logs and Debugging Info
+
+1. **Telemetry test runner logs**
+
+    **_Useful Content:_** Best place to start. These logs contain all of the
+    python logging information from the telemetry test runner scripts. 
+
+    **_Where to find:_** These logs can be found from the buildbot build page.
+    Click the _"[stdout]"_ link under any of the telemetry test buildbot steps
+    to view the logs. Do not use the "stdio" link which will show similiar
+    information but will expire earilier and be slower to load.
+
+2. **Android Logcat (Android)**
+
+    **_Useful Content:_** This file contains all Android device logs. All 
+    Android apps and the Android system will log information to logcat. Good
+    place to look if you believe an issue is device related
+    (Android out-of-memory problem for example). Additionally, often information
+    about native crashes will be logged to here.
+
+    **_Where to find:_** These logs can be found from the buildbot status page.
+    Click the _"logcat dump"_ link under one of the _"gsutil upload"_ steps.
+
+3. **Test Trace (Android)**
+
+    **_Useful Content:_** These logs graphically depict the start/end times for
+    all telemetry tests on all of the devices. This can help determine if test
+    failures were caused by an environmental issue.
+    (see [Cross-Device Failures](#Android-Cross-Device-Failures))
+
+    **_Where to find:_** These logs can be found from the buildbot status page.
+    Click the _"Test Trace"_ link under one of the
+    _"gsutil Upload Test Trace"_ steps.
+
+4. **Symbolized Stack Traces (Android)**
+
+    **_Useful Content:_** Contains symbolized stack traces of any Chrome or
+    Android crashes.
+
+    **_Where to find_:** These logs can be found from the buildbot status page.
+    The symbolized stack traces can be found under several steps. Click link
+    under _"symbolized breakpad crashes"_ step to see symbolized Chrome crashes.
+    Click link under _"stack tool with logcat dump"_ to see symbolized Android
+    crashes.
+
 ### Disabling Telemetry Tests
 
 If the test is a telemetry test, its name will have a '.' in it, such as
 `thread_times.key_mobile_sites` or `page_cycler.top_10`. The part before the
 first dot will be a python file in [tools/perf/benchmarks](https://code.google.com/p/chromium/codesearch#chromium/src/tools/perf/benchmarks/).
 
 If a telemetry test is failing and there is no clear culprit to revert
 immediately, disable the test. You can do this with the `@benchmark.Disabled`
 decorator. **Always add a comment next to your decorator with the bug id which
 has background on why the test was disabled, and also include a BUG= line in
@@ skipping 52 matching lines @@
 
 **[Pri-2 bugs](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=label%3APerformance-Sheriff-BotHealth+label%3APri-2)**
 are for disabled tests. These should be pinged weekly, and work towards fixing
 should be ongoing when the sheriff is not working on a Pri-1 issue. Here is the
 [list of Pri-2 bugs that have not been pinged in a week](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=label:Performance-Sheriff-BotHealth%20label:Pri-2%20modified-before:today-7&sort=modified).
 
 <!-- Unresolved issues:
 1. Do perf sheriffs watch the bisect waterfall?
 2. Do perf sheriffs watch the internal clank waterfall?
 -->