Populates redirects file with initial values (#97) (#98)

Author: sarahsimpers

source/monitoring-alerts.txt

@@ -58,7 +58,9 @@ Features
      - Deployment metrics provide insight into hardware performance and
        database operation efficiency. |service| collects metrics for
        your servers, databases, and MongoDB processes and stores metrics
-       data at various granularity levels. For each granularity level,
+       data at :atlas:`various granularity levels 
+       </monitor-cluster-metrics/#premium-monitoring-granularity>`. For
+       each granularity level,
        |service| computes metrics as averages of the reported metrics at
        the next finer granularity level. Many metrics have a burst
        reporting equivalent. 
@@ -159,14 +161,19 @@ login attempts, unusual access patterns, and data breaches. In dev and
 test environments, we recommend configuring alerts on {+clusters+} after
 seven days of inactivity to save costs. 
 
+When you :atlas:`view alerts in the {+atlas-ui+} 
+</alert-resolutions/#view-alerts>`, we recommend that you use
+available filters to limit results by host, replica set, cluster,
+shard, and more to help focus on the most critical alerts.
+
 Recommended {+service+} Alert Configurations
 ````````````````````````````````````````````
 
 At the minimum, we recommend configuring the following alerts. These
 alerts recommendations provide a baseline, but you should adjust them
 based on your workload characteristics. Where "high priority" conditions
-are specified, we recommend that you configure multiple alerts for the
-same condition, one for a low priority / "warning" level of severity, and one for a high priority level of severity.
+are specified in the following table, we recommend that you configure
+multiple alerts for the same condition, one for a low priority level of severity, and one for a high priority level of severity. This allows you to configure alert notification settings for each separately.
 
 .. list-table:: 
    :header-rows: 1