Fix some broken links, remove outdated pages. (mozilla#376)

* Fix some broken links, remove outdated pages.

Author: mreid-moz

src/SUMMARY.md

@@ -29,8 +29,6 @@
     * [Working with Normandy events](cookbooks/normandy_events.md)
   * [Real-time](cookbooks/realtime.md)
     * [Seeing Your Own Pings](cookbooks/view_pings_cep.md)
-    * [CEP Matcher](tools/cep_matcher.md)
-    * [Creating a Real-time Analysis Plugin](cookbooks/realtime_analysis_plugin.md)
   * [Metrics](cookbooks/metrics.md)
     * [Daily Active Users (DAU)](cookbooks/dau.md)
     * [Active DAU (aDAU)](cookbooks/active_dau.md)

src/concepts/analysis_gotchas.md

@@ -16,7 +16,7 @@ Instead, it is about quirks and pitfalls specific to [Telemetry][telem].
 When looking at trends, it is helpful to be aware of events from the past
 that might impact comparisons with history. Here are a few to keep in mind:
 
-- **December 4 2019** - [AWS Ingestion Pipeline decommissioned](bug1598815).
+- **December 4 2019** - [AWS Ingestion Pipeline decommissioned][bug1598815].
   Specifically, the last ping relayed through the AWS machinery had a
   timestamp of `2019-12-04 22:04:45.912204 UTC`.
 - **October 29 2019** - Glean SDK Timing Distribution(s) are reporting buckets

src/concepts/pipeline/data_pipeline.md

@@ -1,8 +1,9 @@
 # An overview of Mozilla’s Data Pipeline
 
-_Note: This article describes the AWS-based pipeline which is being retired;
-the client-side concepts here still apply, but this article will be updated
-to reflect the new GCP pipeline._
+*Note: This article describes the AWS-based pipeline which
+[has been retired](https://bugzilla.mozilla.org/show_bug.cgi?id=1598815);
+the client-side concepts here still apply, but this article has been updated
+to reflect the [new GCP pipeline](gcp_data_pipeline.md).*
 
 This post describes the architecture of Mozilla’s data pipeline, which is used to collect Telemetry data from our users and logs from various services. One of the cool perks of working at Mozilla is that most of what we do is out in the open and because of that I can do more than just show you some diagram with arrows of our architecture; I can point you to the code, script & configuration that underlies it!
 
@@ -187,7 +188,7 @@ There is a vast ecosystem of tools for processing data at scale, each with their
 [Heka]: https://github.com/mozilla-services/heka
 [plugins]: https://github.com/mozilla-services/hindsight/blob/9593668e84a642aff9dd95ccc648b6585948abfe/docs/index.md
 [UI]: https://github.com/mozilla-services/hindsight_admin
-[access the UI]: https://pipeline-cep.prod.mozaws.net/
+[access the UI]: BROKEN:https://pipeline-cep.prod.mozaws.net/
 [reads pings from Kafka]: https://github.com/mozilla-services/lua_sandbox_extensions/blob/0895238e32d25241ef46f561e43039beb201c7cd/kafka/sandboxes/heka/input/kafka.lua
 [pre-processes]: https://github.com/mozilla-services/lua_sandbox_extensions/blob/5d8907ee9f1a20e3a02bfe5b57d4312b173487a3/moz_telemetry/io_modules/decoders/moz_telemetry/ping.lua
 [sends batches to S3]: https://github.com/mozilla-services/lua_sandbox_extensions/blob/5d8907ee9f1a20e3a02bfe5b57d4312b173487a3/moz_telemetry/sandboxes/heka/output/moz_telemetry_s3.lua

src/concepts/pipeline/data_pipeline_detail.md

@@ -178,7 +178,7 @@ Analysis outputs can also be made public using the **Public Outputs** bucket. Th
 
 Stream processing is done using [Hindsight] and [Spark Streaming].
 
-Hindsight allows you to run [plugins written in Lua inside a sandbox][lua_sandbox]. This gives a safe, performant way to do self-serve streaming analysis. See [this article](../../cookbooks/realtime_analysis_plugin.md) for an introduction. Hindsight plugins do the initial data validation and decoding, as well as writing out to long-term storage in both [Heka-framed protobuf][heka_protobuf] and [parquet][direct2parquet] forms.
+Hindsight allows you to run [plugins written in Lua inside a sandbox][lua_sandbox]. This gives a safe, performant way to do self-serve streaming analysis. Hindsight plugins do the initial data validation and decoding, as well as writing out to long-term storage in both [Heka-framed protobuf][heka_protobuf] and [parquet][direct2parquet] forms.
 
 Spark Streaming is used to read from Kafka and perform [low-latency ETL and aggregation tasks][telemetry-streaming]. These aggregates are currently used by [Mission Control] and are also available for querying via [Re:dash].
 
@@ -393,7 +393,7 @@ graph LR
 [Databricks docs]: https://docs.databricks.com/user-guide/notebooks/index.html
 [tmo]: https://telemetry.mozilla.org
 [measurement dashboard]: https://telemetry.mozilla.org/new-pipeline/dist.html
-[cep]: http://pipeline-cep.prod.mozaws.net/
+[cep]: BROKEN:http://pipeline-cep.prod.mozaws.net/
 [Mission Control]: https://data-missioncontrol.dev.mozaws.net
 [Metrics Graphics]: http://metricsgraphicsjs.org/
 [parquet]: http://parquet.apache.org/

src/cookbooks/realtime_analysis_plugin.md

@@ -1,6 +1,10 @@
 Telemetry Alerts
 ================
 
+*Note: This article describes the AWS-based pipeline which has been retired;
+A new mechanism for alerting on probe expiry is tracked in
+[Bug 1511035](https://bugzilla.mozilla.org/show_bug.cgi?id=1511035).*
+
 Many Telemetry probes were created to show performance trends over time.
 Sudden changes happening in Nightly could be the sign of an
 unintentional performance regression, so we introduced a system to
@@ -29,7 +33,7 @@ It places all detected changes in a file for ingestion by Medusa.
 ### Medusa
 
 Medusa is in charge of emailing people when distributions change and for
-displaying the website <https://alerts.telemetry.mozilla.org> which
+displaying the [Telemetry Alerts] website which
 contains pertinent information about each detected regression.
 
 Medusa also checks for expiring histograms and sends emails notifying of
@@ -70,7 +74,7 @@ One of the main ways humans interact with Telemetry Alerts is through
 the emails sent by Medusa.
 
 At present the email contains a link to the alert's page on
-<https://alerts.telemetry.mozilla.org> and a link to a pushlog on
+[Telemetry Alerts] and a link to a pushlog on
 <https://hg.mozilla.org> detailing the changes newly-present in the
 Nightly build that exhibited the change.
 
@@ -179,3 +183,5 @@ probe again, that is. File a bug in that bug's component to update the
 Alerting probe to have a valid, monitored `alert_emails` field so that
 the next time it misbehaves *they* can be the ones to explain themselves
 without you having to spend all this time tracking them down.
+
+[Telemetry Alerts]: BROKEN:https://alerts.telemetry.mozilla.org