edit pass: log-articles-batch-7

Author: paulth1

articles/azure-monitor/logs/data-ingestion-time.md

@@ -35,8 +35,8 @@ Agents and management solutions use different strategies to collect data from a
 | Windows events, Syslog events, and performance metrics | Collected immediately| |
 | Linux performance counters | Polled at 30-second intervals| |
 | IIS logs and text logs | Collected after their timestamp changes | For IIS logs, this schedule is influenced by the [rollover schedule configured on IIS](../agents/data-sources-iis-logs.md). |
-| Active Directory Replication solution | Assessment every five days | The agent collects these logs only when assessment is complete.|
-| Active Directory Assessment solution | Weekly assessment of your Active Directory infrastructure | The agent collects these logs only when assessment is complete.|
+| Active Directory Replication solution | Assessment every five days | The agent collects the logs only when assessment is complete.|
+| Active Directory Assessment solution | Weekly assessment of your Active Directory infrastructure | The agent collects the logs only when assessment is complete.|
 
 ### Agent upload frequency
 
@@ -85,7 +85,7 @@ Another process that adds latency is the process that handles custom logs. In so
 
 ### New custom data types provisioning
 
-When a new type of custom data is created from a [custom log](../agents/data-sources-custom-logs.md) or the [Data Collector API](../logs/data-collector-api.md), the system creates a dedicated storage container. This is a one-time overhead that occurs only on the first appearance of this data type.
+When a new type of custom data is created from a [custom log](../agents/data-sources-custom-logs.md) or the [Data Collector API](../logs/data-collector-api.md), the system creates a dedicated storage container. This one-time overhead occurs only on the first appearance of this data type.
 
 ### Surge protection
 
@@ -108,7 +108,7 @@ Ingestion time might vary for different resources under different circumstances.
 |:---|:---|:---|
 | Record created at data source | [TimeGenerated](./log-standard-columns.md#timegenerated) <br>If the data source doesn't set this value, it will be set to the same time as _TimeReceived. | If at processing time the Time Generated value is older than 3 days, the row will be dropped. |
 | Record received by Azure Monitor ingestion endpoint | [_TimeReceived](./log-standard-columns.md#_timereceived) | This field isn't optimized for mass processing and shouldn't be used to filter large datasets. |
-| Record stored in workspace and available for queries | [ingestion_time()](/azure/kusto/query/ingestiontimefunction) | We recommend using ingestion_time() if there's a need to filter only records that were ingested in a certain time window. In such cases, we recommend also adding a `TimeGenerated` filter with a larger range. |
+| Record stored in workspace and available for queries | [ingestion_time()](/azure/kusto/query/ingestiontimefunction) | We recommend using `ingestion_time()` if there's a need to filter only records that were ingested in a certain time window. In such cases, we recommend also adding a `TimeGenerated` filter with a larger range. |
 
 ### Ingestion latency delays
 You can measure the latency of a specific record by comparing the result of the [ingestion_time()](/azure/kusto/query/ingestiontimefunction) function to the `TimeGenerated` property. This data can be used with various aggregations to discover how ingestion latency behaves. Examine some percentile of the ingestion time to get insights for large amounts of data.
@@ -137,7 +137,7 @@ Heartbeat
 | render timechart
 ```
 
-Use the following query to show computer ingestion time by the country/region they're located in, which is based on their IP address:
+Use the following query to show computer ingestion time by the country/region where they're located, which is based on their IP address:
 
 ``` Kusto
 Heartbeat 
@@ -160,7 +160,7 @@ AzureDiagnostics
 ### Resources that stop responding
 In some cases, a resource could stop sending data. To understand if a resource is sending data or not, look at its most recent record, which can be identified by the standard `TimeGenerated` field.
 
-Use the _Heartbeat_ table to check the availability of a VM because a heartbeat is sent once a minute by the agent. Use the following query to list the active computers that haven’t reported heartbeat recently:
+Use the `Heartbeat` table to check the availability of a VM because a heartbeat is sent once a minute by the agent. Use the following query to list the active computers that haven’t reported heartbeat recently:
 
 ``` Kusto
 Heartbeat  

articles/azure-monitor/logs/get-started-queries.md

@@ -35,7 +35,7 @@ Here's a video version of this tutorial:
 
 ## Write a new query
 
-Queries can start with either a table name or the *search* command. It's a good idea to start with a table name because it defines a clear scope for the query. It also improves query performance and the relevance of the results.
+Queries can start with either a table name or the `search` command. It's a good idea to start with a table name because it defines a clear scope for the query. It also improves query performance and the relevance of the results.
 
 > [!NOTE]
 > KQL, which is used by Azure Monitor, is case sensitive. Language keywords are usually written in lowercase. When you use names of tables or columns in a query, be sure to use the correct case, as shown on the schema pane.
@@ -49,11 +49,11 @@ SecurityEvent
 | take 10
 ```
 
-The preceding query returns 10 results from the *SecurityEvent* table, in no specific order. This common way to get a glance at a table helps you to understand its structure and content. Let's examine how it's built:
+The preceding query returns 10 results from the `SecurityEvent` table, in no specific order. This common way to get a glance at a table helps you to understand its structure and content. Let's examine how it's built:
 
-* The query starts with the table name *SecurityEvent*, which defines the scope of the query.
+* The query starts with the table name `SecurityEvent`, which defines the scope of the query.
 * The pipe (|) character separates commands, so the output of the first command is the input of the next. You can add any number of piped elements.
-* Following the pipe is the **take** command, which returns a specific number of arbitrary records from the table.
+* Following the pipe is the `take` command, which returns a specific number of arbitrary records from the table.
 
 We could run the query even without adding `| take 10`. The command would still be valid, but it could return up to 10,000 results.
 
@@ -66,36 +66,36 @@ search in (SecurityEvent) "Cryptographic"
 | take 10
 ```
 
-This query searches the *SecurityEvent* table for records that contain the phrase "Cryptographic." Of those records, 10 records will be returned and displayed. If you omit the `in (SecurityEvent)` part and run only `search "Cryptographic"`, the search will go over *all* tables. The process would then take longer and be less efficient.
+This query searches the `SecurityEvent` table for records that contain the phrase "Cryptographic." Of those records, 10 records will be returned and displayed. If you omit the `in (SecurityEvent)` part and run only `search "Cryptographic"`, the search will go over *all* tables. The process would then take longer and be less efficient.
 
 > [!IMPORTANT]
 > Search queries are ordinarily slower than table-based queries because they have to process more data.
 
 ## Sort and top
-Although **take** is useful for getting a few records, the results are selected and displayed in no particular order. To get an ordered view, you could **sort** by the preferred column:
+Although `take` is useful for getting a few records, the results are selected and displayed in no particular order. To get an ordered view, you could `sort` by the preferred column:
 
 ```Kusto
 SecurityEvent	
 | sort by TimeGenerated desc
 ```
 
-The preceding query could return too many results though, and it might also take some time. The query sorts the entire *SecurityEvent* table by the *TimeGenerated* column. The Analytics portal then limits the display to only 10,000 records. This approach isn't optimal.
+The preceding query could return too many results though, and it might also take some time. The query sorts the entire `SecurityEvent` table by the `TimeGenerated` column. The Analytics portal then limits the display to only 10,000 records. This approach isn't optimal.
 
-The best way to get only the latest 10 records is to use **top**, which sorts the entire table on the server side and then returns the top records:
+The best way to get only the latest 10 records is to use `top`, which sorts the entire table on the server side and then returns the top records:
 
 ```Kusto
 SecurityEvent
 | top 10 by TimeGenerated
 ```
 
-Descending is the default sorting order, so you would usually omit the **desc** argument. The output looks like this example.
+Descending is the default sorting order, so you would usually omit the `desc` argument. The output looks like this example.
 
 ![Screenshot that shows the top 10 records sorted in descending order.](media/get-started-queries/top10.png)
 
 ## The where operator: Filter on a condition
 Filters, as indicated by their name, filter the data by a specific condition. Filtering is the most common way to limit query results to relevant information.
 
-To add a filter to a query, use the **where** operator followed by one or more conditions. For example, the following query returns only *SecurityEvent* records where _Level_ equals _8_:
+To add a filter to a query, use the `where` operator followed by one or more conditions. For example, the following query returns only `SecurityEvent` records where `Level equals _8`:
 
 ```Kusto
 SecurityEvent
@@ -109,27 +109,27 @@ When you write filter conditions, you can use the following expressions:
 | == | Check equality<br>(case-sensitive) | `Level == 8` |
 | =~ | Check equality<br>(case-insensitive) | `EventSourceName =~ "microsoft-windows-security-auditing"` |
 | !=, <> | Check inequality<br>(both expressions are identical) | `Level != 4` |
-| *and*, *or* | Required between conditions| `Level == 16 or CommandLine != ""` |
+| `and`, `or` | Required between conditions| `Level == 16 or CommandLine != ""` |
 
 To filter by multiple conditions, you can use either of the following approaches:
 
-Use **and**, as shown here:
+Use `and`, as shown here:
 
 ```Kusto
 SecurityEvent
 | where Level == 8 and EventID == 4672
 ```
 
-Pipe multiple **where** elements, one after the other, as shown here:
+Pipe multiple `where` elements, one after the other, as shown here:
 
 ```Kusto
 SecurityEvent
 | where Level == 8 
 | where EventID == 4672
 ```
-	
+
 > [!NOTE]
-> Values can have different types, so you might need to cast them to perform comparisons on the correct type. For example, the *SecurityEvent Level* column is of type String, so you must cast it to a numerical type, such as *int* or *long*, before you can use numerical operators on it, as shown here:
+> Values can have different types, so you might need to cast them to perform comparisons on the correct type. For example, the `SecurityEvent Level` column is of type String, so you must cast it to a numerical type, such as `int` or `long`, before you can use numerical operators on it, as shown here:
 > `SecurityEvent | where toint(Level) >= 10`
 
 ## Specify a time range
@@ -156,7 +156,7 @@ In the preceding time filter, `ago(30m)` means "30 minutes ago." This query retu
 
 ## Use project and extend to select and compute columns
 
-Use **project** to select specific columns to include in the results:
+Use `project` to select specific columns to include in the results:
 
 ```Kusto
 SecurityEvent 
@@ -168,19 +168,19 @@ The preceding example generates the following output:
 
 ![Screenshot that shows the query "project" results list.](media/get-started-queries/project.png)
 
-You can also use **project** to rename columns and define new ones. The next example uses **project** to do the following:
+You can also use `project` to rename columns and define new ones. The next example uses `project` to do the following:
 
-* Select only the *Computer* and *TimeGenerated* original columns.
-* Display the *Activity* column as *EventDetails*.
-* Create a new column named *EventCode*. The **substring()** function is used to get only the first four characters from the **Activity** field.
+* Select only the `Computer` and `TimeGenerated` original columns.
+* Display the `Activity` column as `EventDetails`.
+* Create a new column named `EventCode`. The `substring()` function is used to get only the first four characters from the `Activity` field.
 
 ```Kusto
 SecurityEvent
 | top 10 by TimeGenerated 
 | project Computer, TimeGenerated, EventDetails=Activity, EventCode=substring(Activity, 0, 4)
 ```
 
-You can use **extend** to keep all original columns in the result set and define other ones. The following query uses **extend** to add the *EventCode* column. This column might not be displayed at the end of the table results. You would need to expand the details of a record to view it.
+You can use `extend` to keep all original columns in the result set and define other ones. The following query uses `extend` to add the `EventCode` column. This column might not be displayed at the end of the table results. You would need to expand the details of a record to view it.
 
 ```Kusto
 SecurityEvent
@@ -189,9 +189,9 @@ SecurityEvent
 ```
 
 ## Use summarize to aggregate groups of rows
-Use **summarize** to identify groups of records according to one or more columns and apply aggregations to them. The most common use of **summarize** is *count*, which returns the number of results in each group.
+Use `summarize` to identify groups of records according to one or more columns and apply aggregations to them. The most common use of `summarize` is `count`, which returns the number of results in each group.
 
-The following query reviews all *Perf* records from the last hour, groups them by *ObjectName*, and counts the records in each group:
+The following query reviews all `Perf` records from the last hour, groups them by `ObjectName`, and counts the records in each group:
 
 ```Kusto
 Perf
@@ -207,15 +207,15 @@ Perf
 | summarize count() by ObjectName, CounterName
 ```
 
-Another common use is to perform mathematical or statistical calculations on each group. The following example calculates the average *CounterValue* for each computer:
+Another common use is to perform mathematical or statistical calculations on each group. The following example calculates the average `CounterValue` for each computer:
 
 ```Kusto
 Perf
 | where TimeGenerated > ago(1h)
 | summarize avg(CounterValue) by Computer
 ```
 
-Unfortunately, the results of this query are meaningless because we mixed together different performance counters. To make the results more meaningful, calculate the average separately for each combination of *CounterName* and *Computer*:
+Unfortunately, the results of this query are meaningless because we mixed together different performance counters. To make the results more meaningful, calculate the average separately for each combination of `CounterName` and `Computer`:
 
 ```Kusto
 Perf
@@ -226,7 +226,7 @@ Perf
 ### Summarize by a time column
 Grouping results can also be based on a time column or another continuous value. Simply summarizing `by TimeGenerated`, though, would create groups for every single millisecond over the time range because these values are unique.
 
-To create groups based on continuous values, it's best to break the range into manageable units by using **bin**. The following query analyzes *Perf* records that measure free memory (*Available MBytes*) on a specific computer. It calculates the average value of each 1-hour period over the last 7 days:
+To create groups based on continuous values, it's best to break the range into manageable units by using `bin`. The following query analyzes `Perf` records that measure free memory (`Available MBytes`) on a specific computer. It calculates the average value of each 1-hour period over the last 7 days:
 
 ```Kusto
 Perf