Merge pull request #251361 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/azure-monitor/agents/azure-monitor-agent-transformation.md

@@ -42,8 +42,8 @@ To complete this procedure, you need:
     For information about the KQL operators that transformations support, see [Structure of transformation in Azure Monitor](../essentials/data-collection-transformations-structure.md#kql-limitations).
 
    > [!Note]
-   > The only columns that are available to apply transfroms against are TimeGenerated and RawData.  Other columns are added to the table automatically after the transformation and are not availiable at the time of transformation.
-   > The _ResourceId column can't be used in the trasnformation.
+   > The only columns that are available to apply transforms against are TimeGenerated and RawData.  Other columns are added to the table automatically after the transformation and are not available at the time of transformation.
+   > The _ResourceId column can't be used in the transformation.
 
     **Example**
 

articles/azure-monitor/app/sampling.md

@@ -268,13 +268,15 @@ In Metrics Explorer, rates such as request and exception counts are multiplied b
     ```
 
 1. **Enable the fixed-rate sampling module.** Add this snippet to [`ApplicationInsights.config`](./configuration-with-applicationinsights-config.md):
+
+    In this example, SamplingPercentage is 20, so **20%** of all items will be sampled. Values in Metrics Explorer will be multiplied by (100/20) = **5** to compensate.
 
     ```xml
     <TelemetryProcessors>
         <Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
             <!-- Set a percentage close to 100/N where N is an integer. -->
             <!-- E.g. 50 (=100/2), 33.33 (=100/3), 25 (=100/4), 20, 1 (=100/100), 0.1 (=100/1000) -->
-            <SamplingPercentage>10</SamplingPercentage>
+            <SamplingPercentage>20</SamplingPercentage>
         </Add>
     </TelemetryProcessors>
     ```

articles/defender-for-cloud/faq-defender-for-storage.yml

@@ -61,7 +61,7 @@ sections:
       - question: |
           How does Defender for Storage monitor Storage accounts?
         answer: |
-          Defender for storage uses Azure Event Grid to monitor the storage account activity. This is result in creation of an Azure Event Grid System topic of name \<StorageAccountName\>-\<Guid\> in the same resource group as the storage account. It will also create an Event Grid Subscription resource named  StorageAntimalwareSubscription.
+          Defender for storage uses Azure Event Grid to monitor the storage account activity. This is result in creation of an Azure Event Grid System topic with the name \<StorageAccountName\>-\<Guid\> in the same resource group as the storage account. It will also create an Event Grid Subscription resource named  StorageAntimalwareSubscription.
 
 
 additionalContent: |

articles/event-hubs/resource-manager-exceptions.md

@@ -35,6 +35,7 @@ The following sections provide various exceptions/errors that are surfaced throu
 | ---------- | ------------- | ------------- | ----------- | -------------- |
 | BadRequest | 40000 | PartitionCount can't be changed for an event hub. | Basic, standard, or premium tier of Azure Event Hubs doesn't support changing partitions. | Create a new event hub with the wanted number of partitions in your basic, standard, or premium tier namespace. Partition scale-out is supported for [dedicated clusters](event-hubs-dedicated-overview.md). |
 | BadRequest | 40000 | The value '#' for MessageRetentionInDays isn't valid for the Basic tier. the value can't exceed '1' day(s). | Basic tier Event Hubs namespaces only support message retention of up to 1 day. | If more than one day of message retention is wanted, [create a standard Event Hubs namespace](event-hubs-create.md). | 
+| BadRequest | 40000 | The event hub can't be disabled. | The Capture feature is enabled for continuous flow of messages. | Disable the Capture feature and then try disabling the event hub. |
 | BadRequest | none | The specified name isn't available. | Namespace names must be unique, and the specified name is already taken. | If you're the owner of the existing namespace with the specified name, you can delete it, which will cause data loss. Then, try again with the same name. If the namespace isn't safe to delete (or you aren't the owner), choose another namespace name. |
 | BadRequest | none | The specified subscription has reached its quota of namespaces. | Your subscription has reached the [quota](event-hubs-quotas.md) for the number of namespaces it can hold. | Consider deleting unused namespaces in this subscription, creating another subscription, or upgrading to a [dedicated cluster](event-hubs-dedicated-overview.md). |
 | BadRequest | none | Can't update a namespace that is secondary | The namespace can't be updated because it's the secondary namespace in a [GeoDR pairing](event-hubs-geo-dr.md). | If appropriate, make the change to the primary namespace in this pairing instead. Otherwise break the GeoDR pairing to make the change. |

articles/healthcare-apis/fhir/how-to-run-a-reindex.md

@@ -105,7 +105,7 @@ content-type: application/fhir+json
 "parameter": [
     {
       "name": "targetSearchParameterTypes",
-      "valueString": "{url of custom search parameter. In case of multiple custom search parameters, url list can be comma seperated.}"
+      "valueString": "{url of custom search parameter. In case of multiple custom search parameters, url list can be comma separated.}"
     }
 ] 
 

articles/iot-hub-device-update/device-update-ubuntu-agent.md

@@ -148,6 +148,10 @@ Read the license terms before you use a package. Your installation and use of a
        },
    ```
 
+   :::image type="content" source="media/import-update/device-twin-ppr.png" alt-text="Screenshot that shows twin with tag information." lightbox="media/import-update/device-twin-ppr.png":::
+
+   _This screenshot shows the section where the tag needs to be added in the twin._
+
 ## Import the update
 
 1. Go to [Device Update releases](https://github.com/Azure/iot-hub-device-update/releases) in GitHub and select the **Assets** dropdown list. Download `Tutorial_IoTEdge_PackageUpdate.zip` by selecting it. Extract the contents of the folder to discover a sample APT manifest (sample-1.0.2-aziot-edge-apt-manifest.json) and its corresponding import manifest (sample-1.0.2-aziot-edge-importManifest.json).

articles/postgresql/flexible-server/concepts-connection-pooling-best-practices.md

@@ -29,8 +29,8 @@ Although there are different tools for connection pooling, in this section, we d
 
 **PgBouncer** is an efficient connection pooler designed for PostgreSQL, offering the advantage of reducing processing time and optimizing resource usage in managing multiple client connections to one or more databases. **PgBouncer** incorporates three distinct pooling mode for connection rotation:
 
-- **Session pooling:** This method assigns a server connection to the client application for the entire duration of the client's connection. Upon disconnection of the client application, **PgBouncer** promptly returns the server connection back to the pool. This pooling mechanism is the default setting. (Note: It isn't recommended in most of the cases and don't give any performance benefits over classic connections).
-- **Transaction pooling:** With transaction pooling, a server connection is dedicated to the client application during a transaction. Once the transaction is successfully completed, **PgBouncer** intelligently releases the server connection, making it available again within the pool. Transaction pooling is the default mode in Flexible server, and it does not support prepared transactions.
+- **Session pooling:** This method assigns a server connection to the client application for the entire duration of the client's connection. Upon disconnection of the client application, **PgBouncer** promptly returns the server connection back to the pool. Session pooling mechanism is the default mode in Open Source PgBouncer. See [PgBouncer configuration](https://www.pgbouncer.org/config.html)
+- **Transaction pooling:** With transaction pooling, a server connection is dedicated to the client application during a transaction. Once the transaction is successfully completed, **PgBouncer** intelligently releases the server connection, making it available again within the pool. Transaction pooling is the default mode in Azure PostgreSQL Flexible Server's in-built PgBouncer, and it does not support prepared transactions.
 - **Statement pooling:** In statement pooling, a server connection is allocated to the client application for each individual statement. Upon the statement's completion, the server connection is promptly returned to the connection pool. It's important to note that multi-statement transactions are not supported in this mode.
 
 The effective utilization of PgBouncer can be categorized into three distinct usage patterns.
@@ -96,29 +96,29 @@ By considering PgBouncer as an AKS sidecar, you can use these advantages to enha
 
 **Limitations:**
 
-- **Connection Performance Issues:** Largehund-scale applications that utilize thousands of pods, each running sidecar PgBouncer, may encounter potential challenges related to database connection exhaustion. This situation can result in performance degradation and service disruptions. Deploying a sidecar PgBouncer for each pod increases the number of concurrent connections to the database server, which can exceed its capacity. As a result, the database may struggle to handle the high volume of incoming connections, may lead to performance issues such as increased response times or even service outages.
+- **Connection Performance Issues:** Large-scale applications that utilize thousands of pods, each running sidecar PgBouncer, may encounter potential challenges related to database connection exhaustion. This situation can result in performance degradation and service disruptions. Deploying a sidecar PgBouncer for each pod increases the number of concurrent connections to the database server, which can exceed its capacity. As a result, the database may struggle to handle the high volume of incoming connections, may lead to performance issues such as increased response times or even service outages.
 - **Complex Deployment:** The utilization of the sidecar pattern introduces a level of complexity to the deployment process, as it involves running two containers within the same pod. This can potentially complicate troubleshooting and debugging activities, requiring extra effort to identify and resolve issues.
-- **Scaling Challenges:** Moreover, it's important to note that the sidecar pattern may not be the ideal choice for applications that demand high scalability. The inclusion of a sidecar container can impose more resource requirements, potentially limiting the number of pods that can be effectively created and managed.
+- **Scaling Challenges:** It's important to note that the sidecar pattern may not be the ideal choice for applications that demand high scalability. The inclusion of a sidecar container can impose more resource requirements, potentially limiting the number of pods that can be effectively created and managed.
 
 While considering this sidecar pattern, it's crucial to carefully assess the trade-offs between deployment complexity and scalability requirements to determine the most appropriate approach for your specific application scenario.
 
-## 2. Application independent - centralized PgBouncer deployment
+## 2. Application independent - Centralized PgBouncer deployment
 
 When utilizing this approach, PgBouncer is deployed as a centralized service, independent of the application. The PgBouncer service can be deployed either on traditional virtual machines or within a microservices-based architecture as highlighted:
 
-### I. PgBouncer deployed in ubuntu VM
+### I. PgBouncer deployed in ubuntu VM behind Azure Load Balancer
 
-**PgBouncer** connection proxy is set up between the application and database layer as shown in the image. Since Azure Database for PostgreSQL is a fully managed platform service, user won't be able to install any external services on DB server. In this case, if your application is running on an Azure VM, you can set up **PgBouncer** on the same VM. If the application is running on a managed service like Azure App Services or Azure Functions, you need to provision a separate Ubuntu VM to run **PgBouncer** proxy.
+**PgBouncer** connection proxy is set up between the application and database layer behind a Azure Load Balancer as shown in the image. In this pattern multiple PgBouncer instances are deployed behind a load balancer as a service to mitigate single point of failure.This pattern is also suitable in scenarios where the application is running on a managed service like Azure App Services or Azure Functions and connecting to **PgBouncer** service for easy integration with your existing infrastructure.
 
 Refer [link](https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/steps-to-install-and-setup-pgbouncer-connection-pooling-proxy/ba-p/730555)  to install and set up PgBouncer connection pooling proxy with Azure Database for PostgreSQL.
 
-
 :::image type="content" source="./media/concepts-connection-pooling-best-practices/deploying-vm.png" alt-text="Diagram for App co-location on Vm with Load Balancer.":::
 
 Some of the key benefits & limitations of this deployment method are:
 
 **Benefits:**
 
+- **Removing Single Point of Failure:** Application connectivity may not be affected by the failure of a single PgBouncer VM, as there are several PgBouncer instances behind Azure Load Balancer.
 - **Seamless Integration with Managed Services:** If your application is hosted on a managed service platform such as Azure App Services or Azure Functions, deploying PgBouncer on a VM allows for easy integration with your existing infrastructure.
 - **Simplified Setup on Azure VM:** If you're already running your application on an Azure VM, setting up PgBouncer on the same VM is straightforward. deploying the  PgBouncer in VM ensures that PgBouncer is deployed in close proximity to your application, minimizing network latency and maximizing performance.
 - **Non-Intrusive Configuration:** By deploying PgBouncer on a VM, you can avoid modifying server parameters on Azure PostgreSQL. This is useful when you want to configure PgBouncer on a flexible server. For example, changing the SSLMODE parameter to "required" on Azure PostgreSQL might cause certain applications that rely on SSLMODE=FALSE to fail. Deploying PgBouncer on a separate VM allows you to maintain the default server configuration while still using PgBouncer's benefits.
@@ -128,7 +128,6 @@ By considering these benefits, deploying PgBouncer on a VM offers a convenient a
 
 **Limitations:**
 
-- **Single point of failure:** As **PgBouncer** is configured on standalone VM, connection pooling might not work if the VM is unavailable. This may result in errors in application connectivity.
 - **Management overhead:** As **PgBouncer** is installed in VM, there might be management overhead to manage multiple configuration files. This makes it difficult to cope up with version upgrades, new releases, and product updates.
 - **Feature parity:** If you're migrating from traditional PostgreSQL to Azure PostgreSQL and using **PgBouncer**, there might be some features gaps. For example, lack of md5 support in Azure PostgreSQL.