fix indenting

Author: rboucher

articles/monitoring-and-diagnostics/alert-log-troubleshoot.md

@@ -33,11 +33,13 @@ As described in the article on [terminology for log alerts](monitor-alerts-unifi
 *For example, If the time period is set to 60 minutes, and the query is run at 1:15 PM, only records created between 12:15 PM and 1:15 PM are used for the log query. If the log query uses a time command like *ago (1d)*, the query still only uses data between 12:15 PM and 1:15 PM because the time period is set to that interval.*
 
 Therefore, check that time period in the configuration matches your query. For the example stated earlier, if the log query uses *ago (1d)* as shown with Green marker, then the time period should be set to 24 hours or 1440 minutes (as indicated in Red), to ensure the query executes as intended.
-    ![Time Period](./media/monitor-alerts-unified/LogAlertTimePeriod.png)
+
+![Time Period](./media/monitor-alerts-unified/LogAlertTimePeriod.png)
 
 ### Suppress Alerts option is set
-As described in step 8 of the article on [creating a log alert rule in Azure portal](alert-log.md#managing-log-alerts-from-the-azure-portal), log alerts provide a **Suppress Alerts** option to suppress triggering and notification actions for a configured amount of time. As a result, you may think that an alert didn't fire while in actuality it did, but was suppressed.    
-    ![Suppress Alerts](./media/monitor-alerts-unified/LogAlertSuppress.png)
+As described in step 8 of the article on [creating a log alert rule in Azure portal](alert-log.md#managing-log-alerts-from-the-azure-portal), log alerts provide a **Suppress Alerts** option to suppress triggering and notification actions for a configured amount of time. As a result, you may think that an alert didn't fire while in actuality it did, but was suppressed.  
+
+![Suppress Alerts](./media/monitor-alerts-unified/LogAlertSuppress.png)
 
 ### Metric measurement alert rule is incorrect
 **Metric measurement log alerts** are a subtype of log alerts, which have special capabilities and a restricted alert query syntax. A metric measurement log alert rule requires the query output to be a metric time series; that is, a table with distinct equally sized time periods along with corresponding aggregated values. Additionally, users can choose to have additional variables in the table alongside AggregatedValue. These variables may be used to sort the table. 
@@ -51,7 +53,7 @@ For example, suppose a metric measurement log alert rule was configured as:
 
 Since the command includes *summarize … by* and provided two variables (timestamp & $table), the system chooses $table to “Aggregate Upon”. It sorts the result table by the field *$table* as shown below and then looks at the multiple AggregatedValue for each table type (like availabilityResults) to see if there was consecutive breaches of 3 or more.
 
-   ![Metric Measurement query execution with multiple values](./media/monitor-alerts-unified/LogMMQuery.png)
+![Metric Measurement query execution with multiple values](./media/monitor-alerts-unified/LogMMQuery.png)
 
 As “Aggregate Upon” is $table – the data is sorted on $table column (as in RED); then we group and look for types of “Aggregate Upon” field (that is) $table – for example: values for availabilityResults will be considered as one plot/entity (as highlighted in Orange). In this value plot/entity – alert service checks for three consecutive breaches occurring (as shown in Green) for which alert will get triggered for table value 'availabilityResults'. Similarly, if for any other value of $table if three consecutive breaches are seen - another alert notification will be triggered for the same; with alert service automatically sorting the values in one plot/entity (as in Orange) by time.