Merge pull request #104698 from HeidiSteen/heidist-monitor

[Azure Cognitive Search] Monitor fixes

Author: PRMerger20

articles/search/search-monitor-usage.md

@@ -15,7 +15,7 @@ ms.date: 02/15/2020
 
 This article introduces monitoring at the service (resource) level, at the workload level (queries and indexing), and suggests a framework for monitoring user access.
 
-Across the spectrum, you'll use a combination of built-in infrastructure and foundational services like Azure Monitor, as well as service APIs that return statistics, counts, and status. Understanding the range of capabilities will help you configure or create an effective communication system for proactive responses to problems as they emerge.
+Across the spectrum, you'll use a combination of built-in infrastructure and foundational services like Azure Monitor, as well as service APIs that return statistics, counts, and status. Understanding the range of capabilities can help you construct a feedback loop so that you can address problems as they emerge.
 
 ## Use Azure Monitor
 
@@ -48,9 +48,9 @@ Tabbed pages built into the Overview page report out on resource usage. This inf
 
 If you are finalizing decisions about [which tier to use for production workloads](search-sku-tier.md), or whether to [adjust the number of active replicas and partitions](search-capacity-planning.md), these metrics can help you with those decisions by showing you how quickly resources are consumed and how well the current configuration handles the existing load.
 
-Alerts related to storage are not currently available; storage consumption is not aggregated or logged into **AzureMetrics**. You would need to build a custom solution to get resource-related notifications.
+Alerts related to storage are not currently available; storage consumption is not aggregated or logged into the **AzureMetrics** table in Azure Monitor. You would need to build a custom solution that emits resource-related notifications, where your code checks for storage size and handles the response. For more information about storage metrics, see [Get Service Statistics](https://docs.microsoft.com/rest/api/searchservice/get-service-statistics#response).
 
-In the portal, the **Usage** tab shows you resource availability relative to current [limits](search-limits-quotas-capacity.md) imposed by the service tier. 
+For visual monitoring in the portal, the **Usage** tab shows you resource availability relative to current [limits](search-limits-quotas-capacity.md) imposed by the service tier. 
 
 The following illustration is for the free service, which is capped at 3 objects of each type and 50 MB of storage. A Basic or Standard service has higher limits, and if you increase the partition counts, maximum storage goes up proportionally.
 
@@ -59,7 +59,7 @@ The following illustration is for the free service, which is capped at 3 objects
 
 ## Monitor workloads
 
-Logged events includes those related to indexing and queries. The **Azure Diagnostics** table in Log Analytics collects operational data related to queries and indexing.
+Logged events includes those related to indexing and queries. The **AzureDiagnostics** table in Log Analytics collects operational data related to queries and indexing.
 
 Most of the logged data is for read-only operations. For other create-update-delete operations not captured in the log, you can query the search service for system information.
 
@@ -111,9 +111,9 @@ Both the Azure Cognitive Search REST API and the .NET SDK provide programmatic a
 
 ## Monitor user access
 
-Because search indexes are a component of a larger client application, there is no built-in, per-user methodology for controlling access to an index. Requests are assumed to come from a client application, for either admin or query requests. Admin read-write operations include creating, updating, deleting objects across the entire service. Read-only operations are queries against the documents collection, scoped to a single index. 
+Because search indexes are a component of a larger client application, there is no built-in methodology for controlling or monitoring per-user access to an index. Requests are assumed to come from a client application, for either admin or query requests. Admin read-write operations include creating, updating, deleting objects across the entire service. Read-only operations are queries against the documents collection, scoped to a single index. 
 
-As such, what you'll see in the logs are references to calls using admin keys or query keys. The appropriate key is included in requests originating from client code. The service is not equipped to handle identity tokens or impersonation.
+As such, what you'll see in the activity logs are references to calls using admin keys or query keys. The appropriate key is included in requests originating from client code. The service is not equipped to handle identity tokens or impersonation.
 
 When business requirements do exist for per-user authorization, the recommendation is integration with Azure Active Directory. You can use $filter and user identities to [trim search results](search-security-trimming-for-azure-search-with-aad.md) of documents that a user should not see.