Merge pull request #218813 from v-jbasden/jbasden-change-blade-to-pane-across-azure-monitor-2

[BULK UPDATE #2] Changing "blade" to "pane"

Author: prmerger-automator[bot]

articles/azure-monitor/app/app-map.md

@@ -400,7 +400,7 @@ Filters can be reused in two ways:
     later time may be different from the one observed when the link was
     created.
 
--   The dashboard pin :::image type="content" source="media/app-map/image-10.png" alt-text="A screenshot displaying the dashboard pin button."::: is located next to the title bar of the Application Map blade. This button pins the map to a dashboard, along with the filters applied to it. This action can be useful for filters that are frequently interesting. As an example, the user can pin a map with "Error connector" filter applied to it, and the dashboard view will only show nodes that have errors in their HTTP calls.
+-   The dashboard pin :::image type="content" source="media/app-map/image-10.png" alt-text="A screenshot displaying the dashboard pin button."::: is located next to the title bar of the Application Map pane. This button pins the map to a dashboard, along with the filters applied to it. This action can be useful for filters that are frequently interesting. As an example, the user can pin a map with "Error connector" filter applied to it, and the dashboard view will only show nodes that have errors in their HTTP calls.
 
 #### Filter usage scenarios
 

articles/azure-monitor/app/java-2x-collectd.md

@@ -88,7 +88,7 @@ Restart collectd according to its [manual](https://collectd.org/wiki/index.php/F
 ## View the data in Application Insights
 In your Application Insights resource, open [Metrics and add charts][metrics], selecting the metrics you want to see from the Custom category.
 
-By default, the metrics are aggregated across all host machines from which the metrics were collected. To view the metrics per host, in the Chart details blade, turn on Grouping and then choose to group by CollectD-Host.
+By default, the metrics are aggregated across all host machines from which the metrics were collected. To view the metrics per host, in the Chart details pane, turn on Grouping and then choose to group by CollectD-Host.
 
 ## To exclude upload of specific statistics
 By default, the Application Insights plugin sends all the data collected by all the enabled collectd 'read' plugins. 

articles/azure-monitor/app/java-2x-get-started.md

@@ -151,7 +151,7 @@ Either run it in debug mode on your development machine, or publish to your serv
 ## View your telemetry in Application Insights
 Return to your Application Insights resource in [Microsoft Azure portal](https://portal.azure.com).
 
-HTTP requests data appears on the overview blade. (If it isn't there, wait a few seconds and then click Refresh.)
+HTTP requests data appears on the overview pane. (If it isn't there, wait a few seconds and then click Refresh.)
 
 ![Screenshot of overview sample data](./media/java-get-started/overview-graphs.png)
 

articles/azure-monitor/app/java-2x-trace-logs.md

@@ -188,7 +188,7 @@ To start getting traces, merge the relevant snippet of code to the Log4J or Logb
 The Application Insights appenders can be referenced by any configured logger, and not necessarily by the root logger (as shown in the code samples above).
 
 ## Explore your traces in the Application Insights portal
-Now that you've configured your project to send traces to Application Insights, you can view and search these traces in the Application Insights portal, in the [Search][diagnostic] blade.
+Now that you've configured your project to send traces to Application Insights, you can view and search these traces in the Application Insights portal, in the [Search][diagnostic] pane.
 
 Exceptions submitted via loggers will be displayed on the portal as Exception Telemetry.
 

articles/azure-monitor/app/java-standalone-profiler.md

@@ -24,7 +24,7 @@ The Application Insights Java profiler uses the JFR profiler provided by the JVM
 
 This data is gathered on demand when trigger conditions are met. The available triggers are thresholds over CPU usage and Memory consumption.
 
-When a threshold is reached, a profile of the configured type and duration is gathered and uploaded. This profile is then visible within the performance blade of the associated Application Insights Portal UI.
+When a threshold is reached, a profile of the configured type and duration is gathered and uploaded. This profile is then visible within the performance pane of the associated Application Insights Portal UI.
 
 > [!WARNING]
 > The JFR profiler by default executes the "profile-without-env-data" profile. A JFR file is a series of events emitted by the JVM. The "profile-without-env-data" configuration, is similar to the "profile" configuration that ships with the JVM, however has had some events disabled that have the potential to contain sensitive deployment information such as environment variables, arguments provided to the JVM and processes running on the system.
@@ -93,8 +93,8 @@ The following steps will guide you through enabling the profiling component on t
 1. Configure the resource thresholds that will cause a profile to be collected:
 
     1. Browse to the Performance -> Profiler section of the Application Insights instance.
-       :::image type="content" source="./media/java-standalone-profiler/performance-blade.png" alt-text="Screenshot of the link to open performance blade." lightbox="media/java-standalone-profiler/performance-blade.png":::
-       :::image type="content" source="./media/java-standalone-profiler/profiler-button.png" alt-text="Screenshot of the Profiler button from the Performance blade." lightbox="media/java-standalone-profiler/profiler-button.png":::
+       :::image type="content" source="./media/java-standalone-profiler/performance-blade.png" alt-text="Screenshot of the link to open performance pane." lightbox="media/java-standalone-profiler/performance-blade.png":::
+       :::image type="content" source="./media/java-standalone-profiler/profiler-button.png" alt-text="Screenshot of the Profiler button from the Performance pane." lightbox="media/java-standalone-profiler/profiler-button.png":::
 
     2. Select "Triggers"
 

articles/azure-monitor/app/monitor-functions.md

@@ -29,7 +29,7 @@ The end-to-end diagnostics and the application map provide visibility into one s
 
 ### How to enable distributed tracing for Java Function apps
 
-Navigate to the functions app Overview blade and go to configurations. Under Application Settings, click "+ New application setting". 
+Navigate to the functions app Overview pane and go to configurations. Under Application Settings, click "+ New application setting". 
 
 > [!div class="mx-imgBorder"]
 > ![Under Settings, add new application settings](./media//functions/create-new-setting.png)

articles/azure-monitor/app/opentelemetry-enable.md

@@ -471,7 +471,7 @@ for i in range(100):
 ---
 
 > [!TIP]
-> If you're not sure where to set the sampling rate, start at 5% (i.e., 0.05 sampling ratio) and adjust the rate based on the accuracy of the operations shown in the failures and performance blades. A higher rate generally results in higher accuracy. However, ANY sampling will affect accuracy so we recommend alerting on [OpenTelemetry metrics](#metrics), which are unaffected by sampling.
+> If you're not sure where to set the sampling rate, start at 5% (i.e., 0.05 sampling ratio) and adjust the rate based on the accuracy of the operations shown in the failures and performance panes. A higher rate generally results in higher accuracy. However, ANY sampling will affect accuracy so we recommend alerting on [OpenTelemetry metrics](#metrics), which are unaffected by sampling.
 
 ## Instrumentation libraries
 

articles/azure-monitor/app/pre-aggregated-metrics-log-metrics.md

@@ -12,7 +12,7 @@ This article explains the difference between "traditional" Application Insights
 
 ## Log-based Metrics
 
-In the past, the application monitoring telemetry data model in Application Insights was solely based on a small number of predefined types of events, such as requests, exceptions, dependency calls, page views, etc. Developers can use the SDK to either emit these events manually (by writing code that explicitly invokes the SDK) or they can rely on the automatic collection of events from auto-instrumentation. In either case, the Application Insights backend stores all collected events as logs, and the Application Insights blades in the Azure portal act as an analytical and diagnostic tool for visualizing event-based data from logs.
+In the past, the application monitoring telemetry data model in Application Insights was solely based on a small number of predefined types of events, such as requests, exceptions, dependency calls, page views, etc. Developers can use the SDK to either emit these events manually (by writing code that explicitly invokes the SDK) or they can rely on the automatic collection of events from auto-instrumentation. In either case, the Application Insights backend stores all collected events as logs, and the Application Insights panes in the Azure portal act as an analytical and diagnostic tool for visualizing event-based data from logs.
 
 Using logs to retain a complete set of events can bring great analytical and diagnostic value. For example, you can get an exact count of requests to a particular URL with the number of distinct users who made these calls. Or you can get detailed diagnostic traces, including exceptions and dependency calls for any user session. Having this type of information can significantly improve visibility into the application health and usage, allowing to cut down the time necessary to diagnose issues with an app.
 

articles/azure-monitor/app/sampling.md

@@ -415,7 +415,7 @@ Use this type of sampling if your app often goes over its monthly quota and you
 
 Set the sampling rate in the Usage and estimated costs page:
 
-![From the application's Overview blade, click Settings, Quota, Samples, then select a sampling rate, and click Update.](./media/sampling/data-sampling.png)
+![From the application's Overview pane, click Settings, Quota, Samples, then select a sampling rate, and click Update.](./media/sampling/data-sampling.png)
 
 Like other types of sampling, the algorithm retains related telemetry items. For example, when you're inspecting the telemetry in Search, you'll be able to find the request related to a particular exception. Metric counts such as request rate and exception rate are correctly retained.
 
@@ -466,7 +466,7 @@ As the application is scaled up, it may be processing dozens, hundreds, or thous
 
 As sampling rates increase log based queries accuracy decrease and are usually inflated. This only impacts the accuracy of log-based queries when sampling is enabled and the sample rates are in a higher range (~ 60%). The impact varies based on telemetry types, telemetry counts per operation as well as other factors.
 
-To address the problems introduced by sampling pre-aggregated metrics are used in the SDKs. Additional details about these metrics, log-based and pre-aggregated, can be referenced in [Azure Application Insights - Azure Monitor | Microsoft Docs](./pre-aggregated-metrics-log-metrics.md#sdk-supported-pre-aggregated-metrics-table). Relevant properties of the logged data are identified and statistics extracted before sampling occurs. To avoid resource and cost issues, metrics are aggregated. The resulting aggregate data is represented by only a few metric telemetry items per minute, instead of potentially thousands of event telemetry items. These metrics calculate the 25 requests from the example and send a metric to the MDM account reporting “this web app processed 25 requests”, but the sent request telemetry record will have an `itemCount` of 100. These pre-aggregated metrics report the correct numbers and can be relied upon when sampling affects the log-based queries results. They can be viewed on the Metrics blade of the Application Insights portal.
+To address the problems introduced by sampling pre-aggregated metrics are used in the SDKs. Additional details about these metrics, log-based and pre-aggregated, can be referenced in [Azure Application Insights - Azure Monitor | Microsoft Docs](./pre-aggregated-metrics-log-metrics.md#sdk-supported-pre-aggregated-metrics-table). Relevant properties of the logged data are identified and statistics extracted before sampling occurs. To avoid resource and cost issues, metrics are aggregated. The resulting aggregate data is represented by only a few metric telemetry items per minute, instead of potentially thousands of event telemetry items. These metrics calculate the 25 requests from the example and send a metric to the MDM account reporting “this web app processed 25 requests”, but the sent request telemetry record will have an `itemCount` of 100. These pre-aggregated metrics report the correct numbers and can be relied upon when sampling affects the log-based queries results. They can be viewed on the Metrics pane of the Application Insights portal.
 
 ## Frequently asked questions
 

articles/azure-monitor/app/sharepoint.md

@@ -79,7 +79,7 @@ Insert a web part and embed the code snippet in it.
 ## View data about your app
 Redeploy your app.
 
-Return to your application blade in the [Azure portal](https://portal.azure.com).
+Return to your application pane in the [Azure portal](https://portal.azure.com).
 
 The first events will appear in Search.