Add documentation in memory_benchmarks.md on finding links to trace files

docs/memory-infra/memory_benchmarks.md

 # Memory Benchmarks
 
 This document describes benchmarks available to track Chrome's and
 WebView's memory usage, where they live, what they measure, how to run them,
 and on how to diagnose regressions.
 
 [TOC]
 
 ## Glossary
 
@@ skipping 74 matching lines @@
 
 *   **Test suite:** The name of a *[benchmark](#Benchmarks)*.
 *   **Bot:** The name of a *platform or device configuration*. Sign in to also
     see internal bots.
 *   **Subtest (1):** The name of a *[metric](#Understanding-memory-metrics)*.
 *   **Subtest (2):** The name of a *story group*; these have the form
     `{interaction}_{category}` for system health stories.
 *   **Subtest (3):** The name of a *[user story](#User-stories)*
     (with `:` replaced by `_`).
 
+If you are investigating a Perf dashboard alert and would like to see the
+details, you can click on any point of the graph. It gives you the commit range,
+buildbot output and a link to the trace file taken during the buildbot run.
+
+![Chrome Performance Dashboard Alert](https://storage.googleapis.com/chromium-docs.appspot.com/perfdashboard_alert.png)

[xunjieli, 2017/06/22 15:55:14]

Primiano: should I rename the filename to contain a hash of some sort to be
consistent with the naming convention? How did you do it?

The gsutil directory seems to have files named after hashes. 
current files are:
gs://chromium-docs.appspot.com/79d08f59cf497c761f7099ea427704c14e9afc03.png
gs://chromium-docs.appspot.com/802141906869cd533bb613da5f91bd0b071ceb24
gs://chromium-docs.appspot.com/a24d80d6a08da088e2e9c8b2b64daa215be4dacb
gs://chromium-docs.appspot.com/a325c4426422e53394a322d31b652cfa34231189
gs://chromium-docs.appspot.com/a73239c6367ed0f844500e51ce1e04556cb99b4f.png
gs://chromium-docs.appspot.com/ea60207d9bb4809178fe75923d6d1a2b241170ef.png
gs://chromium-docs.appspot.com/ec61c5f15705f5bcf3ca83a155ed647a0538bbe1

[Primiano Tucci (use gerrit), 2017/06/23 08:53:41]

Doesn't really matter. I think those hashes came from using
upload_to_google_storage (part of depot tools). But if you managed to upload
stuff manually with just gsutil works anyways :)

[xunjieli, 2017/06/23 12:51:28]

Acknowledged. Got it. Thank you.

+
 ## How to run the benchmarks
 
 Benchmarks may be run on a local platform/device or remotely on a try job.
 
 ### How to run locally
 
 After building, e.g. `ChromePublic.apk`, you can run a specific system health
 story with the command:
 
 ```
@@ skipping 58 matching lines @@
 Most memory metrics have the form
 `memory:{browser}:{processes}:{source}:{component}:{kind}`
 where:
 
 *   **browser:** One of `chrome` or `webview`.
 *   **processess:** One of `browser_process`, `renderer_processess`,
     `gpu_process`, or `all_processess`.
 *   **source:** One of `reported_by_chrome` or `reported_by_os`
 *   **component:** May be a Chrome component, e.g. `skia` or `sqlite`;
     details about a specific component, e.g. `v8:heap`; or a class of memory
-    as seen by the OS, e.g. `system_memory:native_heap` or `gpu_memory`.
+    as seen by the OS, e.g. `system_memory:native_heap` or `gpu_memory`. If
+    reported by chrome, the metrics are gathered by `MemoryDumpProvider`s,
+    probes placed in the specific components' codebase. For example, in
+    "memory:chrome:all_processes:reported_by_chrome:net:effective_size_avg,"
+    the component is "net" which is Chrome's network stack and
+    "reported_by_chrome" means that this metric is gathered via probes in
+    the network stack.
 *   **kind:** The kind of memory being reported. For metrics reported by
     Chrome this usually is `effective_size` (others are `locked_size`
     and `allocated_objects_size`); for metrics by the OS this usually is
     `proportional_resident_size` (others are `peak_resident_size` and
     `private_dirty_size`).
 
 [memory-infra]: /memory-infra/README.md
 
 ## Appendix
 
@@ skipping 45 matching lines @@
 
     Story groups are either `on_chrome` or `on_webview`, indicating the browser
     in foreground at the moment when the memory measurement was made.
 
 *   [memory.long_running_dual_browser_test][memory_extra_py] - same as above,
     but the test is run for 60 iterations keeping both browsers alive for the
     whole duration of the test and without forcing garbage collection. Intended
     as a last-resort net to catch memory leaks not apparent on shorter tests.
 
 [memory_extra_py]: https://cs.chromium.org/chromium/src/tools/perf/contrib/memory_extras/memory_extras.py