Fixing grammar errors

Author: Brunoga-MS

articles/azure-monitor/essentials/data-collection-rule-best-practices.md

@@ -33,10 +33,10 @@ Infact, it's not ideal, even not recommended, to create a single DCR containing
 | Category | Best practice | Explanation | Impact area |
 |:---|:---|:---|:---|
 
-| Data Collection | Define the observability scope | Defining the observability scope is key to an easier and succesfull DCR management and organization obervability scope. It will help clarifing what the collection need is, and from which target virtual machine it should be performed. As previously explained, an observability scope could be a set of virtual machine running a software which is common to a specific application, a set of common information for the IT deparment, etc. As an example, collecting the basic operating system performance counter, such as CPU utilization, available memory and free disk space, could be seen as scope for the Central IT Management. | Not having a clearly defined scope doesn't bring clarity and doesn't allow for a proper management. | 
+| Data Collection | Define the observability scope | Defining the observability scope is key to an easier and succesful DCR management and organization observability scope. It will help clarifying what the collection need is, and from which target virtual machine it should be performed. As previously explained, an observability scope could be a set of virtual machine running a software which is common to a specific application, a set of common information for the IT department, etc. As an example, collecting the basic operating system performance counter, such as CPU utilization, available memory and free disk space, could be seen as scope for the Central IT Management. | Not having a clearly defined scope doesn't bring clarity and doesn't allow for a proper management. | 
 
 | | Create DCRs specific to the observability scope | Creating separate DCRs based on the observability scope is key for easy maintenance. It will allow you to easily associate the DCRs to the relevant target virtual machines. | Why creating a single DCR that collects operating system performance counters plus web server counters and database counters all together? This approach, not only will forces each and every associated virtual machine to transfer, process and execute configuration that is outside of the scope but also will require more effort when the DCR configuration needs to be updated. Think about managing a template that includes unnecessary entries; this situation is less than ideal and leaves room for errors. |
 
-| | Create DCR specific to data source type inside the defined oberservability scope(s) | Creating separate DCRs for performance and events will help in both managing the configuration and the association with granularity based on the target machines. For instance, creating a DCR to collect both events and performance counters could result in an unoptimal approach. There could be situations in which a given machine (or set of machines) doesn't have the event logs or performance counters configured in the DCR. In this situation, the virtual machine(s) will be forced to process and execute a configuration that isn't necessary according to the software installed on it. | Not using different DCRs will force each and every associated virtual machine to transfer, process and execute configuration that might be not applicable according to the installed software. An excessive compute resource consumption and errors in processing configuration might happen causing the [Azure Monitor Agent (AMA)](../overview.md) becoming unresponsive. Moreover, collecting unnecessary data will increase data ingestion costs. |
+| | Create DCR specific to data source type inside the defined obrservability scope(s) | Creating separate DCRs for performance and events will help in both managing the configuration and the association with granularity based on the target machines. For instance, creating a DCR to collect both events and performance counters could result in an unoptimal approach. There could be situations in which a given machine (or set of machines) doesn't have the event logs or performance counters configured in the DCR. In this situation, the virtual machine(s) will be forced to process and execute a configuration that isn't necessary according to the software installed on it. | Not using different DCRs will force each and every associated virtual machine to transfer, process and execute configuration that might be not applicable according to the installed software. An excessive compute resource consumption and errors in processing configuration might happen causing the [Azure Monitor Agent (AMA)](../overview.md) becoming unresponsive. Moreover, collecting unnecessary data will increase data ingestion costs. |
 
 | Data destination | Create different DCR based on the destination | DCRs have the capability of sending data to multiple different destinations, like Azure Monitor Metrics and Azure Monitor Logs, simultaneously. Having DCR(s) specific to destination is helpful in managing the data sovereign or law requirements. Since, being compliant might require to send data only to allowed repositories created in allowed regions, having different DCRs allows for a better granular destination targeting | Not separating DCRs based on the data destination, might result in being not compliant with data handling, privacy and access requirements and could make unnecessary data collection resulting in unexpected costs. |