fixes

Author: bwren

articles/azure-monitor/containers/container-insights-cost.md

@@ -13,13 +13,12 @@ Kubernetes clusters generate a large amount of data that's collected by Containe
 Once you've analyzed your collected data and determined if there's any data that you're collecting that you don't require, there are several options to filter any data that you don't want to collect. This ranges from selecting from a set of predefined cost configurations to leveraging different features to filter data based on specific criteria. This article provides a walkthrough of guidance on how to analyze and optimize your data collection for Container insights. 
 
 
-| [Configure pricing tiers](#configure-pricing-tiers) | Analyze whether configuring basic pricing tier for your container logs will reduce your costs based on your particular usage. You can also use transformations to break up different data into multiple tables using different tiers. |
 
 ## Analyze your data ingestion
 
 To identify your best opportunities for cost savings, analyze the amount of data being collected in different tables. This information will help you identify which tables are consuming the most data and help you make informed decisions about how to reduce costs.
 
-You can visualize how much data is ingested in each workspace by using the **Container Insights Usage** runbook, which is available from the **Workspace** page of of a monitored cluster. 
+You can visualize how much data is ingested in each workspace by using the **Container Insights Usage** runbook, which is available from the **Workspace** page of a monitored cluster. 
 
 :::image type="content" source="media/container-insights-cost/workbooks-page.png" lightbox="media/container-insights-cost/workbooks-page.png" alt-text="Screenshot that shows the View Workbooks dropdown list.":::
 
@@ -69,7 +68,7 @@ See [Data transformations in Container insights](./container-insights-transforma
 
 ## Configure pricing tiers
 
-[Basic Logs in Azure Monitor](../logs/logs-table-plans.md) offer a significant cost discount for ingestion of data in your Log Analytics workspace for data that that you occasionally use for debugging and troubleshooting. Tables configured for basic logs offer a significant cost discount for data ingestion in exchange for a cost for log queries meaning that they're ideal for data that you require but that you access infrequently. 
+[Basic Logs in Azure Monitor](../logs/logs-table-plans.md) offer a significant cost discount for ingestion of data in your Log Analytics workspace for data that you occasionally use for debugging and troubleshooting. Tables configured for basic logs offer a significant cost discount for data ingestion in exchange for a cost for log queries meaning that they're ideal for data that you require but that you access infrequently. 
 
 [ContainerLogV2](container-insights-logs-schema.md) can be configured for basic logs which can give you significant cost savings if you query the data infrequently. Using [transformations](#transformations), you can specify data that should be sent to alternate tables configured for basic logs. See [Data transformations in Container insights](./container-insights-transformations.md) for an example of this strategy.
 

articles/azure-monitor/containers/container-insights-data-collection-configure.md

@@ -1,6 +1,6 @@
 ---
 title: Configure Container insights data collection
-description: Details on configuring data collection in Azure Monitor Container insights after you enable it on on your Kubernetes cluster.
+description: Details on configuring data collection in Azure Monitor Container insights after you enable it on your Kubernetes cluster.
 ms.topic: conceptual
 ms.date: 05/14/2024
 ms.reviewer: aul
@@ -16,7 +16,7 @@ There are two methods use to configure and filter data being collected in Contai
 | Method | Description |
 |:---|:---| 
 | [Data collection rule (DCR)](#configure-data-collection-using-dcr) | [Data collection rules](../essentials/data-collection-rule-overview.md) are sets of instructions supporting data collection using the [Azure Monitor pipeline](../essentials/pipeline-overview.md). A DCR is created when you enable Container insights, and you can modify the settings in this DCR either using the Azure portal or other methods. | 
-| [ConfigMap](#configure-data-collection-using-configmap) | [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) are a Kubernetes mechanism that allow you to store non-confidential data such as a configuration file or environment variables. Container insights looks for a ConfigMap on each cluster with particular settings that define data that it should collect.|
+| [ConfigMap](#configure-data-collection-using-configmap) | [ConfigMaps](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) are a Kubernetes mechanism that allows you to store non-confidential data such as a configuration file or environment variables. Container insights looks for a ConfigMap on each cluster with particular settings that define data that it should collect.|
 
 ## Configure data collection using DCR
 The DCR created by Container insights is named *MSCI-\<cluster-region\>-\<cluster-name\>*. You can [view this DCR](../essentials/data-collection-rule-view.md) along with others in your subscription, and you can edit it using methods described in [Create and edit data collection rules (DCRs) in Azure Monitor](../essentials/data-collection-rule-create-edit.md). While you can directly modify the DCR for particular customizations, you can perform most required configuration using the methods described below. See [Data transformations in Container insights](./container-insights-transformations.md) for details on editing the DCR directly for more advanced configurations.
@@ -127,7 +127,7 @@ Use the following command to create a new AKS cluster with monitoring enabled. T
 az aks create -g <clusterResourceGroup> -n <clusterName> --enable-managed-identity --node-count 1 --enable-addons monitoring --data-collection-settings dataCollectionSettings.json --generate-ssh-keys 
 ```
 
-#### Existing AKS Cluster
+#### Existing AKS cluster
 
 **Cluster without the monitoring addon**
 Use the following command to add monitoring to an existing cluster without Container insights enabled. This assumes a configuration file named **dataCollectionSettings.json**.
@@ -156,7 +156,7 @@ Use the following command to add monitoring to an existing Arc-enabled Kubernete
 az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true dataCollectionSettings='{"interval":"1m","namespaceFilteringMode": "Include", "namespaces": [ "kube-system"],"enableContainerLogV2": true,"streams": ["<streams to be collected>"]}'
 ```
 
-### AKS hybrid Cluster
+### AKS hybrid cluster
 Use the following command to add monitoring to an existing AKS hybrid cluster.
 
 ```azcli

articles/azure-monitor/containers/container-insights-data-collection-filter.md

@@ -39,7 +39,7 @@ The following example shows the ConfigMap settings to collect stdout and stderr
 ```
 
 
-## Platform log filtering (System Kubernetes Namespaces)
+## Platform log filtering (System Kubernetes namespaces)
 By default, container logs from the system namespace are excluded from collection to minimize the Log Analytics cost. Container logs of system containers can be critical though in specific troubleshooting scenarios. This feature is restricted to the following system namespaces:  `kube-system`, `gatekeeper-system`, `calico-system`, `azure-arc`, `kube-public`, and `kube-node-lease`.
 
 Enable platform logs using [ConfigMap](./container-insights-data-collection-configure.md#configure-data-collection-using-configmap) with the `collect_system_pod_logs` setting. You must also ensure that the system namespace is not in the `exclude_namespaces` setting. 
@@ -107,7 +107,7 @@ Enable collection of environment variables across all pods and nodes in the clus
     enabled = true
 ```
 
-If collection of environment variables is globally enabled, you can disable it for a specific container by setting the environment variable `AZMON_COLLECT_ENV` to `False` either with a Dockerfile setting or in the [configuration file for the Pod](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) under the `env:` section. If collection of environment variables is globally disabled, you can't enable collection for a specific container. The only override that can be applied at the container level is to disable collectdion when it's already enabled globally.
+If collection of environment variables is globally enabled, you can disable it for a specific container by setting the environment variable `AZMON_COLLECT_ENV` to `False` either with a Dockerfile setting or in the [configuration file for the Pod](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) under the `env:` section. If collection of environment variables is globally disabled, you can't enable collection for a specific container. The only override that can be applied at the container level is to disable collection when it's already enabled globally.
 
 
 

articles/azure-monitor/containers/container-insights-log-query.md

@@ -631,7 +631,7 @@ The required tables for this chart include KubeNodeInventory, KubePodInventory,
 
 ## Prometheus metrics
 
-The following examples requires the configuration described in [Send Prometheus metrics to Log Analytics workspace with Container insights](container-insights-prometheus-logs.md).
+The following examples require the configuration described in [Send Prometheus metrics to Log Analytics workspace with Container insights](container-insights-prometheus-logs.md).
 
 To view Prometheus metrics scraped by Azure Monitor and filtered by namespace, specify *"prometheus"*. Here's a sample query to view Prometheus metrics from the `default` Kubernetes namespace.
 

articles/azure-monitor/containers/container-insights-logs-schema.md

@@ -30,7 +30,7 @@ The following table highlights the key differences between using ContainerLogV2
 | Querying | Requires multiple join operations with inventory tables for standard queries. | Includes additional pod and container metadata to reduce query complexity and join operations. |
 | Multiline | Not supported, multiline entries are split into multiple rows. | Support for multiline logging to allow consolidated, single entries for multiline output. |
 
-<sup>1</sup> If `LogMessage` is valid JSON and has a key named `level`, its value will be used. Otherwise, regex based keyword matching is used to infer `LogLevel` from `LogMessage`. This inference may results in some misclassifications. `LogLevel` is a string field with a health value such as `CRITICAL`, `ERROR`, `WARNING`, `INFO`, `DEBUG`, `TRACE`, or `UNKNOWN`.
+<sup>1</sup> If `LogMessage` is valid JSON and has a key named `level`, its value will be used. Otherwise, regex based keyword matching is used to infer `LogLevel` from `LogMessage`. This inference may result in some misclassifications. `LogLevel` is a string field with a health value such as `CRITICAL`, `ERROR`, `WARNING`, `INFO`, `DEBUG`, `TRACE`, or `UNKNOWN`.
 
 <sup>2</sup> `KubernetesMetadata` is an optional column that is enabled with [Kubernetes metadata](). The value of this field is JSON with the fields `podLabels`, `podAnnotations`, `podUid`, `Image`, `ImageTag`, and `Image repo`.
 

articles/azure-monitor/containers/container-insights-transformations.md

@@ -164,7 +164,7 @@ The following sample shows this transformation added to the Container insights D
 
 In the example above, only records with a `LogLevel` of `error` or `critical` are collected. An alternate strategy instead of not collecting these records at all is to save them to an alternate table configured for basic logs. 
 
-For this strategy, two transformation are needed. The first transformation sends the records with `LogLevel` of `error` or `critical` to the default table. The second transformation sends the other records to a custom table named `ContainerLogV2_CL`. The queries for each are shown below using `source` for the incoming data as described in the previous example.
+For this strategy, two transformations are needed. The first transformation sends the records with `LogLevel` of `error` or `critical` to the default table. The second transformation sends the other records to a custom table named `ContainerLogV2_CL`. The queries for each are shown below using `source` for the incoming data as described in the previous example.
 
 ```kusto
 # Return error and critical logs

articles/azure-monitor/containers/kubernetes-monitoring-enable.md

@@ -525,7 +525,7 @@ Both ARM and Bicep templates are provided in this section.
 
 ### [Azure Policy](#tab/policy)
 
-#### Azure Portal
+#### Azure portal
 
 1. From the **Definitions** tab of the **Policy** menu in the Azure portal, create a policy definition with the following details.