PR review changes

Author: jonburchel

articles/data-factory/how-to-configure-shir-for-log-analytics-collection.md

@@ -1,7 +1,7 @@
 ---
-title: Configuring the self-hosted integration runtime for log analytics collection
+title: Configure the self-hosted integration runtime for log analytics collection
 titleSuffix: Azure Data Factory & Azure Synapse
-description: This topic describes how to instrument the self-hosted integration runtime for log analytics collection.
+description: This article describes how to instrument the self-hosted integration runtime for log analytics collection.
 author: jonburchel
 ms.service: data-factory
 ms.subservice: 
@@ -11,64 +11,61 @@ ms.date: 02/22/2022
 ms.author: jburchel
 ---
 
-# Configuring the self-hosted integration runtime (SHIR) for log analytics collection
+# Configure the self-hosted integration runtime (SHIR) for log analytics collection
 [!INCLUDE[appliesto-adf-asa-md](includes/appliesto-adf-asa-md.md)]
 
 ## Prerequisites
 
-An available Log Analytics workspace is required for this approach.
-
-- We recommended you note down the workspace ID and authentication Key of your Log Analytics workspace as you might need it for certain scenarios.
-- This solution will increase the data that will be sent to the Log Analytics workspace and will have a small impact on overall cost. Please read on for details on how to keep the amount of data to a minimum.
+An available Log Analytics workspace is required for this approach. We recommended you note down the workspace ID and authentication Key of your Log Analytics workspace as you might need it for certain scenarios. This solution will increase the data that will be sent to the Log Analytics workspace and will have a small impact on overall cost. Read on for details on how to keep the amount of data to a minimum.
 
 ## Objectives and scenarios
 
-Centralize the events and the performance counter data to your Log Analytics workspace, first the virtual machine hosting the SHIR must be appropriately instrumented. Please choose between two main scenarios below.
+Centralize the events and the performance counter data to your Log Analytics workspace, first the virtual machine hosting the SHIR must be appropriately instrumented. Choose between two main scenarios below.
 
 ### Instrumenting on-premises virtual machines
 
-The article [Install Log Analytics agent on Windows computers](../azure-monitor/agents/agent-windows.md) describes how to install the client on a virtual machine typically hosted on-premises. This can be either a physical server or a virtual machine hosted on a customer managed hypervisor. As mentioned in the prerequisite section, when installing the Log Analytics agent, you will have to provide the Log Analytics workspace ID and Workspace Key to finalize the connection.
+The article [Install Log Analytics agent on Windows computers](../azure-monitor/agents/agent-windows.md) describes how to install the client on a virtual machine typically hosted on-premises. This can be either a physical server or a virtual machine hosted on a customer managed hypervisor. As mentioned in the prerequisite section, when installing the Log Analytics agent, you'll have to provide the Log Analytics workspace ID and Workspace Key to finalize the connection.
 
-### Instrumenting Azure virtual machines
+### Instrument Azure virtual machines
 
-The recommended approach to instrument an Azure virtual machine based SHIR is to use virtual machine insights as described in the article [Enable VM insights overview](../azure-monitor/vm/vminsights-enable-overview.md).  Note that there are multiple ways to configure the Log Analytics agent when the SHIR is hosted in an Azure virtual machine. All the options are described in the article [Log Analytics agent overview](../azure-monitor/agents/log-analytics-agent.md#installation-options).
+The recommended approach to instrument an Azure virtual machine based SHIR is to use virtual machine insights as described in the article [Enable VM insights overview](../azure-monitor/vm/vminsights-enable-overview.md).  There are multiple ways to configure the Log Analytics agent when the SHIR is hosted in an Azure virtual machine. All the options are described in the article [Log Analytics agent overview](../azure-monitor/agents/log-analytics-agent.md#installation-options).
 
-## Configuring event log and performance counter capture
+## Configure event log and performance counter capture
 
-This step will highlight how to configure both Event viewer logs and performance counters to be captured and sent over to Log Analytics. The steps described below are common regardless of how the agent was deployed.
+This step will highlight how to configure both Event viewer logs and performance counters to be sent to Log Analytics. The steps described below are common regardless of how the agent was deployed.
 
-### Selecting event viewer journals
+### Select event viewer journals
 
 First you must collect event viewer journals relevant to the SHIR as described in the article [Collect Windows event log data sources with Log Analytics agent in Azure Monitor](../azure-monitor/agents/data-sources-windows-events.md).
 
-It's important to note that when choosing the event logs using the interface, it is normal that you will not see all journals that can possibly exist on a machine. Consequently, the two journals that we need for SHIR monitoring will not show up in this list. If you type the journal name exactly as it appears on the local virtual machine, it will be captured and sent to your Log analytics workspace.
+It's important to note that when choosing the event logs using the interface, it's normal that you won't see all journals that can possibly exist on a machine. So, the two journals that we need for SHIR monitoring won't show up in this list. If you type the journal name exactly as it appears on the local virtual machine, it will be captured and sent to your Log analytics workspace.
 
 The event journal name we must configure are:
 
 - Connectors – Integration Runtime
 - Integration Runtime
 
-:::image type="content" source="media/how-to-configure-shir-for-log-analytics-collection/configure-journals-for-collection.png" alt-text="Shows the selection of the SHIR relevant logs with errors and warnings checked.":::
+:::image type="content" source="media/how-to-configure-shir-for-log-analytics-collection/configure-journals-for-collection.png" alt-text="Screenshot of the selection of the SHIR relevant logs with errors and warnings checked.":::
 
 > [!IMPORTANT]
 > Leaving the **Information** level checked will increase the volume of data significantly if you have many SHIR hosts deployed and a larger number of scans. We strongly suggest you keep only Error and Warning.
 
-### Selecting Performance counters
+### Select Performance counters
 
-In the same configuration pane, you can click on **Windows Performance Counters** to select individual performance counters to send up to log analytics. Keep in mind that performance counters are, by their nature, a continuous data stream. Therefore, it’s crucial that you consider the impact of data collection on the total cost of your Azure Monitor/Log Analytics deployment. Unless an allowed data ingestion budget has been granted and a constant ingestion of data has been allowed and budgeted for, gathering performance counters should only be configured for a defined period to establish a performance baseline. 
+In the same configuration pane, you can select on **Windows Performance Counters** to select individual performance counters to send up to log analytics. Keep in mind that performance counters are, by their nature, a continuous data stream. Therefore, it’s crucial that you consider the impact of data collection on the total cost of your Azure Monitor/Log Analytics deployment. Unless an allowed data ingestion budget has been granted and a constant ingestion of data has been allowed and budgeted for, gathering performance counters should only be configured for a defined period to establish a performance baseline. 
 
-In the interface, when first configuring it, a suggested counter set will be recommended. Select those that apply to the type of performance analysis you want to perform. **%CPU** and **Available memory** are commonly monitored counters but others like **Network bandwidth consumption** can be useful in scenarios where the data volume are large, and bandwidth or execution time are constrained.
+In the interface, when first configuring it, a suggested counter set will be recommended. Select those that apply to the type of performance analysis you want to perform. **%CPU** and **Available memory** are commonly monitored counters but others like **Network bandwidth consumption** can be useful in scenarios where the data volume is large, and bandwidth or execution time are constrained.
 
-:::image type="content" source="media/how-to-configure-shir-for-log-analytics-collection/select-counters.png" alt-text="Shows the counter selection interface in the Azure portal.":::
+:::image type="content" source="media/how-to-configure-shir-for-log-analytics-collection/select-counters.png" alt-text="Screenshot of the counter selection interface in the Azure portal.":::
 
-## Viewing Events and Performance counter data in Log Analytics
+## View Events and Performance counter data in Log Analytics
 
-Please consult this tutorial on [How to query data in Log Analytics](../azure-monitor/logs/log-analytics-tutorial.md).
+Consult this tutorial on [How to query data in Log Analytics](../azure-monitor/logs/log-analytics-tutorial.md).
 The two tables where the telemetry is saved are called Perf and Event respectively. The following query will check the row count to see if we have data flowing in. This would confirm if the instrumentation described above is working.
 
 ### Sample KQL queries
 
-#### Checking row counts
+#### Check row counts
 
 ```kusto
 (
@@ -84,23 +81,23 @@ The two tables where the telemetry is saved are called Perf and Event respective
 )
 ```
 
-#### Querying events
+#### Query events
 
-##### Retrieving the first 10 event rows
+##### Retrieve the first 10 event rows
 
 ```kusto
 Event
 | take 10
 ```
 
-##### Retrieving the event count by message severity
+##### Retrieve the event count by message severity
 
 ```kusto
 Event
 | summarize count() by EventLevelName
 ```
 
-##### Rendering a pie chart of count by message severity
+##### Render a pie chart of count by message severity
 
 ```kusto
 Event
@@ -110,7 +107,7 @@ Event
 
 ##### Retrieve all errors with a particular text string
 
-Here we are searching for all message that have the word _disconnected_ in them.
+Here we are searching for all messages that have the word _disconnected_ in them.
 
 ```kusto
 Event
@@ -119,7 +116,7 @@ Event
 
 ##### Multi-table search for a keyword without knowing the schema
 
-The search command is useful when one does not know which column the information is contained in. This query returns all rows from the specified tables that has at least one column that contains the search term. The word is _disconnected_ in this example.
+The search command is useful when one does not know which column the information is contained in. This query returns all rows from the specified tables that have at least one column that contains the search term. The word is _disconnected_ in this example.
 
 ```kusto
 search in (Perf, Event) "disconnected"
@@ -134,7 +131,7 @@ Event
 | where EventLog == "Connectors – Integration Runtime"
 ```
 
-##### Using timespans to restrict query results
+##### Use timespans to restrict query results
 
 This query uses the same query as above but restricts results to those occurring 2 days ago or more recently.
 
@@ -146,14 +143,14 @@ Event
 
 #### Query performance counter data
 
-##### Getting the first 10 performance counter readings
+##### Retrieve the first 10 performance counter readings
 
 ```kusto
 Perf
 | take 10
 ```
 
-##### Getting a specific counter with time constraints 
+##### Retrieve a specific counter with time constraints 
 
 ```kusto
 Perf
@@ -165,7 +162,7 @@ Perf
 
 Performance counters are hierarchical in nature, so be mindful to have enough _where_ predicates in your query to select only the specific counter you need.
 
-##### 95th percentile for a given counter binned by 30 minute slices of the last 24 hours
+##### Retrieve 95th percentile for a given counter binned by 30 minute slices of the last 24 hours
 
 This example is all the counters for a specific network adapter.
 
@@ -178,7 +175,7 @@ Perf
 | summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName
 ```
 
-##### Using variables for code reusability
+##### Use variables for code reusability
 
 Here we are making the object name and counter name a variable so we do not have to change the KQL query body to make changes to those selections later.
 
@@ -192,5 +189,8 @@ Perf
 | summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated
 ```
 
+## Next Steps
 
+- [Review integration runtime concepts in Azure Data Factory.](concepts-integration-runtime.md)
+- Learn how to [create a self-hosted integration runtime in the Azure portal.](create-self-hosted-integration-runtime.md)
 

articles/data-factory/monitor-shir-in-azure.md

@@ -1,7 +1,7 @@
 ---
-title: Monitoring self-hosted intgegration runtime (SHIR) virtual machines in Azure
+title: Monitor self-hosted integration runtime (SHIR) virtual machines in Azure
 titleSuffix: Azure Data Factory & Azure Synapse
-description: This topic describes how to monitor Azure virtual machines hosting the self-hosted integration runtime.
+description: This article describes how to monitor Azure virtual machines hosting the self-hosted integration runtime.
 author: jonburchel
 ms.service: data-factory
 ms.subservice: 
@@ -11,19 +11,25 @@ ms.date: 02/22/2022
 ms.author: jburchel
 ---
 
-# Monitoring self-hosted intgegration runtime (SHIR) virtual machines in Azure
+# Monitor self-hosted integration runtime (SHIR) virtual machines in Azure
 [!INCLUDE[appliesto-adf-asa-md](includes/appliesto-adf-asa-md.md)]
 
 By default, the Self Hosted Integration Runtime’s diagnostic and performance telemetry is saved locally on the virtual or physical machine that is hosting it. Two broad categories of telemetry are of interest for monitoring the Self Hosted Integration Runtime.
 
 ## Event logs
 
-When logged on locally to the Self Hosted Integration Runtime, specific events can be viewed using the [event viewer](/windows/win32/eventlog/viewing-the-event-log.md). The relevant events are captured in two event viewer journals named: **Connectors – Integration Runtime** and **Integration Runtime** respectively. While it’s possible to log in to the Self Hosted Integration Runtime hosts individually to view these events, it is also possible to stream these events to a Log Analytics workspace in Azure monitor for ease of query and centralization purposes.
+When logged on locally to the Self Hosted Integration Runtime, specific events can be viewed using the [event viewer](/windows/win32/eventlog/viewing-the-event-log.md). The relevant events are captured in two event viewer journals named: **Connectors – Integration Runtime** and **Integration Runtime** respectively. While it’s possible to log on to to the Self Hosted Integration Runtime hosts individually to view these events, it's also possible to stream these events to a Log Analytics workspace in Azure monitor for ease of query and centralization purposes.
 
 ## Performance counters
 
 Performance counters in Windows and Linux provide insight into the performance of hardware components, operating systems, and applications such as the Self Hosted Integration Runtime. The performance counters can be viewed and collected locally on the VM using the performance monitor tool. See the article on [using performance counters](/windows/win32/perfctrs/using-performance-counters.md) for more details. 
 
-## Centralizing log collection and analysis
+## Centralize log collection and analysis
 
-When a deployment requires a more in-depth level of analysis or has reached a certain scale, it becomes impractical to log on locally to each Self Hosted Integration Runtime host. Therefore, we recommend leveraging Azure Monitor and Azure Log Analytics specifically to collect that data and enable a single pane of glass monitoring for your Self Hosted Integration Runtimes. See the article on [Configuring the SHIR for log analytics collection](how-to-configure-shir-for-log-analytics-collection.md) for instructions on how to instrument your Self Hosted Integration Runtimes for Azure Monitor.
+When a deployment requires a more in-depth level of analysis or has reached a certain scale, it becomes impractical to log on to locally to each Self Hosted Integration Runtime host. Therefore, we recommend using Azure Monitor and Azure Log Analytics specifically to collect that data and enable a single pane of glass monitoring for your Self Hosted Integration Runtimes. See the article on [Configuring the SHIR for log analytics collection](how-to-configure-shir-for-log-analytics-collection.md) for instructions on how to instrument your Self Hosted Integration Runtimes for Azure Monitor.
+
+## Next Steps
+
+- [How to configure SHIR for log analytics collection](how-to-configure-shir-for-log-analytics-collection.md)
+- [Review integration runtime concepts in Azure Data Factory.](concepts-integration-runtime.md)
+- Learn how to [create a self-hosted integration runtime in the Azure portal.](create-self-hosted-integration-runtime.md)