Merge pull request #272106 from MicrosoftDocs/main

Publish to live, Sunday 4 AM PST, 4/14

Author: ttorble

.openpublishing.redirection.iot-develop.json

@@ -29,7 +29,9 @@ To start developing a voice assistant for Windows, you need to make sure
 Some resources necessary for a customized voice agent on Windows requires resources from Microsoft. The [UWP Voice Assistant Sample](windows-voice-assistants-faq.yml#the-uwp-voice-assistant-sample) provides sample versions of these resources for initial development and testing, so this section is unnecessary for initial development.
 
 - **Keyword model:** Voice activation requires a keyword model from Microsoft in the form of a .bin file. The .bin file provided in the UWP Voice Assistant Sample is trained on the keyword *Contoso*.
-- **Limited Access Feature Token:** Since the ConversationalAgent APIs provide access to microphone audio, they're protected under Limited Access Feature restrictions. To use a Limited Access Feature, you need to obtain a Limited Access Feature token connected to the package identity of your application from Microsoft.
+- **Limited Access Feature Token:** Since the ConversationalAgent APIs provide access to microphone audio, they're protected under Limited Access Feature restrictions. To use a Limited Access Feature, you need to obtain a Limited Access Feature token connected to the package identity of your application from Microsoft. For more information about any Limited Access Feature or to request an unlock token, contact [Microsoft Support](https://support.serviceshub.microsoft.com/supportforbusiness/create?sapId=d15d3aa2-0512-7cb8-1df9-86221f5cbfde).
+
+
 
 ## Establish a dialog service
 

articles/ai-services/speech-service/how-to-windows-voice-assistants-get-started.md

@@ -12,6 +12,9 @@ You may not need to continuously run your Azure Kubernetes Service (AKS) workloa
 
 To better optimize your costs during these periods, you can turn off, or stop, your cluster. This action stops your control plane and agent nodes, allowing you to save on all the compute costs, while maintaining all objects except standalone pods. The cluster state is stored for when you start it again, allowing you to pick up where you left off.
 
+> [!CAUTION]
+> Stopping your cluster deallocates the control plane and releases the capacity. In regions experiencing capacity constraints, customers may be unable to start a stopped cluster. We do not recommend stopping mission critical workloads for this reason.
+
 ## Before you begin
 
 This article assumes you have an existing AKS cluster. If you need an AKS cluster, you can create one using [Azure CLI][aks-quickstart-cli], [Azure PowerShell][aks-quickstart-powershell], or the [Azure portal][aks-quickstart-portal].

articles/aks/start-stop-cluster.md

@@ -198,7 +198,7 @@ Create the AKS cluster and specify `--network-plugin azure`, and `--network-poli
 If you plan on adding Windows node pools to your cluster, include the `windows-admin-username` and `windows-admin-password` parameters that meet the [Windows Server password requirements][windows-server-password].
 
 > [!IMPORTANT]
-> At this time, using Calico network policies with Windows nodes is available on new clusters by using Kubernetes version 1.20 or later with Calico 3.17.2 and requires that you use Azure CNI networking. Windows nodes on AKS clusters with Calico enabled also have [Direct Server Return (DSR)][dsr] enabled by default.
+> At this time, using Calico network policies with Windows nodes is available on new clusters by using Kubernetes version 1.20 or later with Calico 3.17.2 and requires that you use Azure CNI networking. Windows nodes on AKS clusters with Calico enabled also have Floating IP enabled by default.
 >
 > For clusters with only Linux node pools running Kubernetes 1.20 with earlier versions of Calico, the Calico version automatically upgrades to 3.17.2.
 

articles/aks/use-network-policies.md

@@ -35,7 +35,7 @@ You might want to containerize existing applications and run them using Windows
 
 AKS uses Windows Server 2019 and Windows Server 2022 as the host OS versions and only supports process isolation. AKS doesn't support container images built by other versions of Windows Server. For more information, see [Windows container version compatibility](/virtualization/windowscontainers/deploy-containers/version-compatibility).
 
-Windows Server 2022 is the default OS for Kubernetes version 1.25 and later. Windows Server 2019 will retire after Kubernetes version 1.32 reaches end of life (EOL). Windows Server 2022 will retire after Kubernetes version 1.34 reaches its end of life (EOL). For more information, see [AKS release notes][aks-release-notes]. To stay up to date on the latest Windows Server OS versions and learn more about our roadmap of what's planned for support on AKS, see our [AKS public roadmap](https://github.com/azure/aks/projects/1).
+Windows Server 2022 is the default OS for Kubernetes version 1.25 and later. Windows Server 2019 will retire after Kubernetes version 1.32 reaches end of life. Windows Server 2022 will retire after Kubernetes version 1.34 reaches its end of life. For more information, see [AKS release notes][aks-release-notes]. To stay up to date on the latest Windows Server OS versions and learn more about our roadmap of what's planned for support on AKS, see our [AKS public roadmap](https://github.com/azure/aks/projects/1).
 
 
 ## Networking
@@ -63,7 +63,7 @@ To help you decide which networking mode to use, see [Choosing a network model][
 
 When managing traffic between pods, you should apply the principle of least privilege. The Network Policy feature in Kubernetes allows you to define and enforce ingress and egress traffic rules between the pods in your cluster. For more information, see [Secure traffic between pods using network policies in AKS][network-policies-aks].
 
-Windows pods on AKS clusters that use the Calico Network Policy enable [Floating IP][dsr] by default.
+Windows pods on AKS clusters that use the Calico Network Policy enable Floating IP by default.
 
 ## Upgrades and updates
 

articles/aks/windows-best-practices.md

@@ -1,12 +1,12 @@
 ---
 title: Configure local metrics and logs for Azure API Management self-hosted gateway | Microsoft Docs
-description: Learn how to configure local metrics and logs for Azure API Management self-hosted gateway on a Kubernetes cluster
+description: Learn how to configure local metrics and logs for Azure API Management self-hosted gateway on a Kubernetes cluster.
 services: api-management
 author: dlepow
 manager: gwallace
 ms.service: api-management
 ms.topic: article
-ms.date: 05/11/2021
+ms.date: 04/12/2024
 ms.author: danlep
 ---
 
@@ -22,7 +22,7 @@ The self-hosted gateway supports [StatsD](https://github.com/statsd/statsd), whi
 
 ### Deploy StatsD and Prometheus to the cluster
 
-Below is a sample YAML configuration for deploying StatsD and Prometheus to the Kubernetes cluster where a self-hosted gateway is deployed. It also creates a [Service](https://kubernetes.io/docs/concepts/services-networking/service/) for each. The self-hosted gateway will publish metrics to the StatsD Service. We will access the Prometheus dashboard via its Service.
+The following sample YAML configuration deploys StatsD and Prometheus to the Kubernetes cluster where a self-hosted gateway is deployed. It also creates a [Service](https://kubernetes.io/docs/concepts/services-networking/service/) for each. The self-hosted gateway then publishes metrics to the StatsD Service. We'll access the Prometheus dashboard via its Service.
 
 > [!NOTE]
 > The following example pulls public container images from Docker Hub. We recommend that you set up a pull secret to authenticate using a Docker Hub account instead of making an anonymous pull request. To improve reliability when working with public content, import and manage the images in a private Azure container registry. [Learn more about working with public images.](../container-registry/buffer-gate-public-content.md)
@@ -119,21 +119,21 @@ spec:
     app: sputnik-metrics
 ```
 
-Save the configurations to a file named `metrics.yaml` and use the below command to deploy everything to the cluster:
+Save the configurations to a file named `metrics.yaml`. Use the following command to deploy everything to the cluster:
 
 ```console
 kubectl apply -f metrics.yaml
 ```
 
-Once the deployment finishes, run the below command to check the Pods are running. Note that your pod name will be different.
+Once the deployment finishes, run the following command to check the Pods are running. Your pod name will be different.
 
 ```console
 kubectl get pods
 NAME                                   READY   STATUS    RESTARTS   AGE
 sputnik-metrics-f6d97548f-4xnb7        2/2     Running   0          1m
 ```
 
-Run the below command to check the Services are running. Take a note of the `CLUSTER-IP` and `PORT` of the StatsD Service, we would need it later. You can visit the Prometheus dashboard using its `EXTERNAL-IP` and `PORT`.
+Run the below command to check the `services` are running. Take a note of the `CLUSTER-IP` and `PORT` of the StatsD Service, which we use later. You can visit the Prometheus dashboard using its `EXTERNAL-IP` and `PORT`.
 
 ```console
 kubectl get services
@@ -144,16 +144,16 @@ sputnik-metrics-statsd       NodePort       10.0.41.179   <none>          8125:3
 
 ### Configure the self-hosted gateway to emit metrics
 
-Now that both StatsD and Prometheus have been deployed, we can update the configurations of the self-hosted gateway to start emitting  metrics through StatsD. The feature can be enabled or disabled using the `telemetry.metrics.local` key in the ConfigMap of the self-hosted gateway Deployment with additional options. Below is a breakdown of the available options:
+Now that both StatsD and Prometheus are deployed, we can update the configurations of the self-hosted gateway to start emitting  metrics through StatsD. The feature can be enabled or disabled using the `telemetry.metrics.local` key in the ConfigMap of the self-hosted gateway Deployment with additional options. The following are the available options:
 
 | Field  | Default | Description |
 | ------------- | ------------- | ------------- |
 | telemetry.metrics.local  | `none` | Enables logging through StatsD. Value can be `none`, `statsd`. |
 | telemetry.metrics.local.statsd.endpoint  | n/a | Specifies StatsD endpoint. |
-| telemetry.metrics.local.statsd.sampling  | n/a | Specifies metrics sampling rate. Value can be between 0 and 1. e.g., `0.5`|
+| telemetry.metrics.local.statsd.sampling  | n/a | Specifies metrics sampling rate. Value can be between 0 and 1. Example: `0.5`|
 | telemetry.metrics.local.statsd.tag-format  | n/a | StatsD exporter [tagging format](https://github.com/prometheus/statsd_exporter#tagging-extensions). Value can be `none`, `librato`, `dogStatsD`, `influxDB`. |
 
-Here is a sample configuration:
+Here's a sample configuration:
 
 ```yaml
 apiVersion: v1
@@ -182,16 +182,16 @@ kubectl rollout restart deployment/<deployment-name>
 
 ### View the metrics
 
-Now we have everything deployed and configured, the self-hosted gateway should report metrics via StatsD. Prometheus will pick up the metrics from StatsD. Go to the Prometheus dashboard using the `EXTERNAL-IP` and `PORT` of the Prometheus Service.
+Now we have everything deployed and configured, the self-hosted gateway should report metrics via StatsD. Prometheus then picks up the metrics from StatsD. Go to the Prometheus dashboard using the `EXTERNAL-IP` and `PORT` of the Prometheus Service.
 
 Make some API calls through the self-hosted gateway, if everything is configured correctly, you should be able to view below metrics:
 
 | Metric        | Description |
 | ------------- | ------------- |
 | requests_total  | Number of API requests in the period |
 | request_duration_seconds | Number of milliseconds from the moment gateway received request until the moment response sent in full |
-| request_backend_duration_seconds | Number of milliseconds spent on overall backend IO (connecting, sending and receiving bytes)  |
-| request_client_duration_seconds | Number of milliseconds spent on overall client IO (connecting, sending and receiving bytes)  |
+| request_backend_duration_seconds | Number of milliseconds spent on overall backend IO (connecting, sending, and receiving bytes)  |
+| request_client_duration_seconds | Number of milliseconds spent on overall client IO (connecting, sending, and receiving bytes)  |
 
 ## Logs
 
@@ -203,20 +203,20 @@ kubectl logs <pod-name>
 
 If your self-hosted gateway is deployed in Azure Kubernetes Service, you can enable [Azure Monitor for containers](../azure-monitor/containers/container-insights-overview.md) to collect `stdout` and `stderr` from your workloads and view the logs in Log Analytics.
 
-The self-hosted gateway also supports a number of protocols including `localsyslog`, `rfc5424`, and `journal`. The below table summarizes all the options supported.
+The self-hosted gateway also supports many protocols including `localsyslog`, `rfc5424`, and `journal`. The following table summarizes all the options supported.
 
 | Field  | Default | Description |
 | ------------- | ------------- | ------------- |
 | telemetry.logs.std  | `text` | Enables logging to standard streams. Value can be `none`, `text`, `json` |
 | telemetry.logs.local  | `auto` | Enables local logging. Value can be `none`, `auto`, `localsyslog`, `rfc5424`, `journal`, `json`  |
-| telemetry.logs.local.localsyslog.endpoint  | n/a | Specifies localsyslog endpoint.  |
-| telemetry.logs.local.localsyslog.facility  | n/a | Specifies localsyslog [facility code](https://en.wikipedia.org/wiki/Syslog#Facility). e.g., `7`
+| telemetry.logs.local.localsyslog.endpoint  | n/a | Specifies local syslog endpoint. For details, see [using local syslog logs](#using-local-syslog-logs).  |
+| telemetry.logs.local.localsyslog.facility  | n/a | Specifies local syslog [facility code](https://en.wikipedia.org/wiki/Syslog#Facility). Example: `7`
 | telemetry.logs.local.rfc5424.endpoint  | n/a | Specifies rfc5424 endpoint.  |
-| telemetry.logs.local.rfc5424.facility  | n/a | Specifies facility code per [rfc5424](https://tools.ietf.org/html/rfc5424). e.g., `7`  |
+| telemetry.logs.local.rfc5424.facility  | n/a | Specifies facility code per [rfc5424](https://tools.ietf.org/html/rfc5424). Example: `7`  |
 | telemetry.logs.local.journal.endpoint  | n/a | Specifies journal endpoint.  |
 | telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | Specifies UDP endpoint that accepts JSON data: file path, IP:port, or hostname:port.
 
-Here is a sample configuration of local logging:
+Here's a sample configuration of local logging:
 
 ```yaml
     apiVersion: v1
@@ -230,9 +230,65 @@ Here is a sample configuration of local logging:
         telemetry.logs.local.localsyslog.facility: "7"
 ```
 
-### Using local syslog logs on Azure Kubernetes Service (AKS)
+### Using local syslog logs
 
-When configuring to use localsyslog on Azure Kubernetes Service, you can choose two ways to explore the logs:
+#### Configuring gateway to stream logs
+
+When using local syslog as a destination for logs, the runtime needs to allow streaming logs to the destination. For Kubernetes, a volume needs to be mounted which that matches the destination.
+
+Given the following configuration:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+    name: contoso-gateway-environment
+data:
+    config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
+    telemetry.logs.local: localsyslog
+    telemetry.logs.local.localsyslog.endpoint: /dev/log
+```
+
+You can easily start streaming logs to that local syslog endpoint:
+
+```diff
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: contoso-deployment
+  labels:
+    app: contoso
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: contoso
+  template:
+    metadata:
+      labels:
+        app: contoso
+    spec:
+      containers:
+        name: azure-api-management-gateway
+        image: mcr.microsoft.com/azure-api-management/gateway:2.5.0
+        imagePullPolicy: IfNotPresent
+        envFrom:
+        - configMapRef:
+            name: contoso-gateway-environment
+        # ... redacted ...
++       volumeMounts:
++       - mountPath: /dev/log
++         name: logs
++     volumes:
++     - hostPath:
++         path: /dev/log
++         type: Socket
++       name: logs
+```
+
+#### Consuming local syslog logs on Azure Kubernetes Service (AKS)
+
+When configuring to use local syslog on Azure Kubernetes Service, you can choose two ways to explore the logs:
 
 - Use [Syslog collection with Container Insights](./../azure-monitor/containers/container-insights-syslog.md)
 - Connect & explore logs on the worker nodes
@@ -256,6 +312,6 @@ May 15 05:54:21 aks-agentpool-43853532-vmss000000 apimuser[8]: Timestamp=2023-05
 
 ## Next steps
 
-* To learn more about the [observability capabilities of the Azure API Management gateways](observability.md).
-* To learn more about the self-hosted gateway, see [Azure API Management self-hosted gateway overview](self-hosted-gateway-overview.md)
-* Learn about [configuring and persisting logs in the cloud](how-to-configure-cloud-metrics-logs.md)
+* Learn about the [observability capabilities of the Azure API Management gateways](observability.md).
+* Learn more about the [Azure API Management self-hosted gateway](self-hosted-gateway-overview.md).
+* Learn about [configuring and persisting logs in the cloud](how-to-configure-cloud-metrics-logs.md).

articles/api-management/how-to-configure-local-metrics-logs.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: api-management
 ms.topic: reference
-ms.date: 06/28/2022
+ms.date: 04/12/2024
 ms.author: danlep
 ---
 
@@ -29,7 +29,7 @@ Here is an overview of all configuration options:
 
 | Name                           | Description              | Required | Default           | Availability |
 |----|------|----------|-------------------|-------------------|
-| gateway.name | Id of the self-hosted gateway resource. | Yes, when using Microsoft Entra authentication | N/A | v2.3+ |
+| gateway.name | ID of the self-hosted gateway resource. | Yes, when using Microsoft Entra authentication | N/A | v2.3+ |
 | config.service.endpoint | Configuration endpoint in Azure API Management for the self-hosted gateway. Find this value in the Azure portal under **Gateways** > **Deployment**.  | Yes       | N/A             | v2.0+ |
 | config.service.auth | Defines how the self-hosted gateway should authenticate to the Configuration API. Currently gateway token and Microsoft Entra authentication are supported. | Yes | N/A | v2.0+ |
 | config.service.auth.azureAd.tenantId | ID of the Microsoft Entra tenant. | Yes, when using Microsoft Entra authentication | N/A | v2.3+ |
@@ -98,7 +98,7 @@ This guidance helps you provide the required information to define how to authen
 | telemetry.logs.std.level  | Defines the log level of logs sent to standard stream. Value is one of the following options: `all`, `debug`, `info`, `warn`, `error` or `fatal`. | No |  `info` | v2.0+ |
 | telemetry.logs.std.color  | Indication whether or not colored logs should be used in standard stream. | No |  `true` | v2.0+ |
 | telemetry.logs.local  | [Enable local logging](how-to-configure-local-metrics-logs.md#logs). Value is one of the following options: `none`, `auto`, `localsyslog`, `rfc5424`, `journal`, `json`  | No  | `auto` | v2.0+ |
-| telemetry.logs.local.localsyslog.endpoint  |  localsyslog endpoint.  | Yes if `telemetry.logs.local` is set to `localsyslog`; otherwise no. | N/A | v2.0+ |
+| telemetry.logs.local.localsyslog.endpoint  |  localsyslog endpoint.  | Yes if `telemetry.logs.local` is set to `localsyslog`; otherwise no. See [local syslog documentation](how-to-configure-local-metrics-logs.md#using-local-syslog-logs) for more details on configuration. | N/A | v2.0+ |
 | telemetry.logs.local.localsyslog.facility  | Specifies localsyslog [facility code](https://en.wikipedia.org/wiki/Syslog#Facility), for example, `7`. | No | N/A | v2.0+ |
 | telemetry.logs.local.rfc5424.endpoint  |  rfc5424 endpoint.  | Yes if `telemetry.logs.local` is set to `rfc5424`; otherwise no. | N/A | v2.0+ |
 | telemetry.logs.local.rfc5424.facility  | Facility code per [rfc5424](https://tools.ietf.org/html/rfc5424), for example, `7`  | No | N/A | v2.0+ |