diff --git a/daprdocs/content/en/concepts/service-mesh.md b/daprdocs/content/en/concepts/service-mesh.md index 0e3c4cf9ef3..d0f686dc3b7 100644 --- a/daprdocs/content/en/concepts/service-mesh.md +++ b/daprdocs/content/en/concepts/service-mesh.md @@ -7,7 +7,7 @@ description: > How Dapr compares to and works with service meshes --- -Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? +Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and [distributed tracing](https://middleware.io/blog/what-is-distributed-tracing/). This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? ## How Dapr and service meshes compare While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric. diff --git a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md index 167d85f986d..afd41751505 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md +++ b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md @@ -69,7 +69,7 @@ spec: allowedSecrets: ["secret1", "secret2"] ``` -The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Scenario 3: Deny access to certain sensitive secrets in a secret store @@ -88,7 +88,7 @@ spec: deniedSecrets: ["secret1", "secret2"] ``` -This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Permission priority diff --git a/daprdocs/content/en/getting-started/install-dapr-cli.md b/daprdocs/content/en/getting-started/install-dapr-cli.md index 21f17968973..da8dee54ee5 100644 --- a/daprdocs/content/en/getting-started/install-dapr-cli.md +++ b/daprdocs/content/en/getting-started/install-dapr-cli.md @@ -16,7 +16,7 @@ You'll use the Dapr CLI as the main tool for various Dapr-related tasks. You can The Dapr CLI works with both [self-hosted]({{< ref self-hosted >}}) and [Kubernetes]({{< ref Kubernetes >}}) environments. {{% alert title="Before you begin" color="primary" %}} -In Docker Desktop's advanced options, verify you've allowed the default Docker socket to be used. +In Docker Desktop's advanced options, verify you've allowed the default Docker socket to be used. This option is not available if you are using WSL integration on Windows. {{% /alert %}} diff --git a/daprdocs/content/en/getting-started/quickstarts/bindings-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/bindings-quickstart.md index 4e40a515912..4597228b7aa 100644 --- a/daprdocs/content/en/getting-started/quickstarts/bindings-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/bindings-quickstart.md @@ -651,7 +651,7 @@ In the YAML file: For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/configuration-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/configuration-quickstart.md index a9c563ba1e0..368a1bd5c22 100644 --- a/daprdocs/content/en/getting-started/quickstarts/configuration-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/configuration-quickstart.md @@ -389,7 +389,7 @@ try For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md index 82d5884424a..abb1293fa19 100644 --- a/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md @@ -512,7 +512,7 @@ Console.WriteLine("Published data: " + order); For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. @@ -1321,7 +1321,7 @@ In the YAML file: For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md index 92f92610738..9e5fe6983ef 100644 --- a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md @@ -693,7 +693,7 @@ dapr run --app-port 7001 --app-id order-processor --app-protocol http --dapr-htt For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md index 8a35d24428f..5ac6d287bbb 100644 --- a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md @@ -61,27 +61,28 @@ Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar the metadata: name: myresiliency scopes: - - checkout - + - order-processor + spec: policies: retries: retryForever: policy: constant - maxInterval: 5s - maxRetries: -1 - + duration: 5s + maxRetries: -1 + circuitBreakers: simpleCB: maxRequests: 1 - timeout: 5s + timeout: 5s trip: consecutiveFailures >= 5 - + targets: - apps: - order-processor: - retry: retryForever - circuitBreaker: simpleCB + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB ``` @@ -533,7 +534,7 @@ INFO[0036] Recovered processing operation component[statestore] output. For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/secrets-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/secrets-quickstart.md index de12598d24f..9d1187e97e2 100644 --- a/daprdocs/content/en/getting-started/quickstarts/secrets-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/secrets-quickstart.md @@ -356,7 +356,7 @@ Order-processor output: For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/serviceinvocation-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/serviceinvocation-quickstart.md index 0164e35fddf..ada18093dfc 100644 --- a/daprdocs/content/en/getting-started/quickstarts/serviceinvocation-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/serviceinvocation-quickstart.md @@ -458,7 +458,7 @@ var response = await client.PostAsync($"{baseURL}/orders", content); For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. @@ -1156,7 +1156,7 @@ Dapr invokes an application on any Dapr instance. In the code, the sidecar progr For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/statemanagement-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/statemanagement-quickstart.md index a0448f0d3dd..95357c4eb20 100644 --- a/daprdocs/content/en/getting-started/quickstarts/statemanagement-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/statemanagement-quickstart.md @@ -419,7 +419,7 @@ In the YAML file: For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. @@ -1050,7 +1050,7 @@ In the YAML file: For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): +- Java JDK 17 (or greater): - [Oracle JDK](https://www.oracle.com/java/technologies/downloads), or - OpenJDK - [Apache Maven](https://maven.apache.org/install.html), version 3.x. diff --git a/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md index 8e1adb0c5fc..9e25597907d 100644 --- a/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/workflow-quickstart.md @@ -7,10 +7,10 @@ description: Get started with the Dapr Workflow building block --- {{% alert title="Note" color="primary" %}} -Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}). +Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-version cli="true" %}}]({{< ref "workflow-overview.md#limitations" >}}). {{% /alert %}} -Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs. +Let's take a look at the Dapr [Workflow building block]({{< ref workflow-overview.md >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs. In this guide, you'll: @@ -29,8 +29,8 @@ Select your preferred language-specific Dapr SDK before proceeding with the Quic The `order-processor` console app starts and manages the `order_processing_workflow`, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks: - `notify_activity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when: - - You have insufficient inventory - - Your payment couldn't be processed, etc. + - You have insufficient inventory + - Your payment couldn't be processed, etc. - `process_payment_activity`: Processes and authorizes the payment. - `verify_inventory_activity`: Checks the state store to ensure there is enough inventory present for purchase. - `update_inventory_activity`: Removes the requested items from the state store and updates the store with the new remaining inventory value. @@ -71,10 +71,11 @@ pip3 install -r requirements.txt In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}): ```bash +cd workflows/python/sdk dapr run -f . ``` -This starts the `order-processor` app with unique workflow ID and runs the workflow activities. +This starts the `order-processor` app with unique workflow ID and runs the workflow activities. Expected output: @@ -105,7 +106,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op docker run -d -p 9411:9411 openzipkin/zipkin ``` -View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). +View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). @@ -122,9 +123,10 @@ When you ran `dapr run -f .`: 1. The `NotifyActivity` workflow activity sends a notification saying that order `f4e1926e-3721-478d-be8a-f5bebd1995da` has completed. 1. The workflow terminates as completed. -#### `order-processor/app.py` +#### `order-processor/app.py` In the application's program file: + - The unique workflow order ID is generated - The workflow is scheduled - The workflow status is retrieved @@ -276,7 +278,6 @@ The `order-processor` console app starts and manages the lifecycle of an order p - `processPaymentActivity`: Processes and authorizes the payment. - `updateInventoryActivity`: Updates the state store with the new remaining inventory value. - ### Step 1: Pre-requisites For this example, you will need: @@ -318,11 +319,11 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M dapr run -f . ``` -This starts the `order-processor` app with unique workflow ID and runs the workflow activities. +This starts the `order-processor` app with unique workflow ID and runs the workflow activities. Expected output: -``` +```log == APP - workflowApp == == APP == Orchestration scheduled with ID: 0c332155-1e02-453a-a333-28cfc7777642 == APP - workflowApp == == APP == Waiting 30 seconds for instance 0c332155-1e02-453a-a333-28cfc7777642 to complete... == APP - workflowApp == == APP == Received "Orchestrator Request" work item with instance id '0c332155-1e02-453a-a333-28cfc7777642' @@ -393,7 +394,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op docker run -d -p 9411:9411 openzipkin/zipkin ``` -View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). +View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). @@ -410,9 +411,10 @@ When you ran `dapr run -f .`: 1. The `notifyActivity` workflow activity sends a notification saying that order `0c332155-1e02-453a-a333-28cfc7777642` has completed. 1. The workflow terminates as completed. -#### `order-processor/workflowApp.ts` +#### `order-processor/workflowApp.ts` In the application file: + - The unique workflow order ID is generated - The workflow is scheduled - The workflow status is retrieved @@ -489,12 +491,12 @@ start().catch((e) => { {{% codetab %}} The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks: + - `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow - `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase - `ProcessPaymentActivity`: Processes and authorizes the payment - `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value - ### Step 1: Pre-requisites For this example, you will need: @@ -513,10 +515,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic git clone https://github.com/dapr/quickstarts.git ``` -In a new terminal window, navigate to the `order-processor` directory: +In a new terminal window, navigate to the `sdk` directory: ```bash -cd workflows/csharp/sdk/order-processor +cd workflows/csharp/sdk ``` ### Step 3: Run the order processor app @@ -527,7 +529,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M dapr run -f . ``` -This starts the `order-processor` app with unique workflow ID and runs the workflow activities. +This starts the `order-processor` app with unique workflow ID and runs the workflow activities. Expected output: @@ -567,7 +569,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op docker run -d -p 9411:9411 openzipkin/zipkin ``` -View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). +View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). @@ -584,9 +586,10 @@ When you ran `dapr run -f .`: 1. The `NotifyActivity` workflow activity sends a notification saying that order `6d2abcc9` has completed. 1. The workflow terminates as completed. -#### `order-processor/Program.cs` +#### `order-processor/Program.cs` In the application's program file: + - The unique workflow order ID is generated - The workflow is scheduled - The workflow status is retrieved @@ -717,6 +720,7 @@ class OrderProcessingWorkflow : Workflow #### `order-processor/Activities` directory The `Activities` directory holds the four workflow activities used by the workflow, defined in the following files: + - `NotifyActivity.cs` - `ReserveInventoryActivity.cs` - `ProcessPaymentActivity.cs` @@ -734,22 +738,22 @@ Watch [this video to walk through the Dapr Workflow .NET demo](https://youtu.be/ {{% codetab %}} The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks: + - `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow - `RequestApprovalActivity`: Requests approval for processing payment - `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase - `ProcessPaymentActivity`: Processes and authorizes the payment - `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value - ### Step 1: Pre-requisites For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- Java JDK 11 (or greater): - - [Microsoft JDK 11](https://docs.microsoft.com/java/openjdk/download#openjdk-11) - - [Oracle JDK 11](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK11) - - [OpenJDK 11](https://jdk.java.net/11/) +- Java JDK 17 (or greater): + - [Microsoft JDK 17](https://docs.microsoft.com/java/openjdk/download#openjdk-17) + - [Oracle JDK 17](https://www.oracle.com/technetwork/java/javase/downloads/index.html#JDK17) + - [OpenJDK 17](https://jdk.java.net/17/) - [Apache Maven](https://maven.apache.org/install.html) version 3.x. - [Docker Desktop](https://www.docker.com/products/docker-desktop) @@ -780,10 +784,11 @@ mvn clean install In the terminal, start the order processor app alongside a Dapr sidecar using [Multi-App Run]({{< ref multi-app-dapr-run >}}): ```bash +cd workflows/java/sdk dapr run -f . ``` -This starts the `order-processor` app with unique workflow ID and runs the workflow activities. +This starts the `order-processor` app with unique workflow ID and runs the workflow activities. Expected output: @@ -826,7 +831,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op docker run -d -p 9411:9411 openzipkin/zipkin ``` -View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). +View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). @@ -1073,7 +1078,6 @@ The `Activities` directory holds the four workflow activities used by the workfl {{% codetab %}} - The `order-processor` console app starts and manages the `OrderProcessingWorkflow` workflow, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks: - `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when: @@ -1102,10 +1106,10 @@ Clone the [sample provided in the Quickstarts repo](https://github.com/dapr/quic git clone https://github.com/dapr/quickstarts.git ``` -In a new terminal window, navigate to the `order-processor` directory: +In a new terminal window, navigate to the `sdk` directory: ```bash -cd workflows/go/sdk/order-processor +cd workflows/go/sdk ``` ### Step 3: Run the order processor app @@ -1116,7 +1120,7 @@ In the terminal, start the order processor app alongside a Dapr sidecar using [M dapr run -f . ``` -This starts the `order-processor` app with unique workflow ID and runs the workflow activities. +This starts the `order-processor` app with unique workflow ID and runs the workflow activities. Expected output: @@ -1157,7 +1161,7 @@ Running `dapr init` launches the [openzipkin/zipkin](https://hub.docker.com/r/op docker run -d -p 9411:9411 openzipkin/zipkin ``` -View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). +View the workflow trace spans in the Zipkin web UI (typically at `http://localhost:9411/zipkin/`). @@ -1174,9 +1178,10 @@ When you ran `dapr run`: 1. The `NotifyActivity` workflow activity sends a notification saying that order `48ee83b7-5d80-48d5-97f9-6b372f5480a5` has completed. 1. The workflow terminates as completed. -#### `order-processor/main.go` +#### `order-processor/main.go` In the application's program file: + - The unique workflow order ID is generated - The workflow is scheduled - The workflow status is retrieved @@ -1317,6 +1322,7 @@ Meanwhile, the `OrderProcessingWorkflow` and its activities are defined as metho {{< /tabs >}} ## Tell us what you think! + We're continuously working to improve our Quickstart examples and value your feedback. Did you find this Quickstart helpful? Do you have suggestions for improvement? Join the discussion in our [discord channel](https://discord.com/channels/778680217417809931/953427615916638238). diff --git a/daprdocs/content/en/operations/configuration/configuration-overview.md b/daprdocs/content/en/operations/configuration/configuration-overview.md index 5b6a4d73df0..af4f3f475a5 100644 --- a/daprdocs/content/en/operations/configuration/configuration-overview.md +++ b/daprdocs/content/en/operations/configuration/configuration-overview.md @@ -110,30 +110,17 @@ metrics: rules: [] http: increasedCardinality: true - pathMatching: - - /items - - /orders/{orderID} - - /orders/{orderID}/items/{itemID} - - /payments/{paymentID} - - /payments/{paymentID}/status - - /payments/{paymentID}/refund - - /payments/{paymentID}/details - excludeVerbs: false ``` -In the examples above, the path filter `/orders/{orderID}/items/{itemID}` would return a single metric count matching all the `orderIDs` and all the `itemIDs`, rather than multiple metrics for each `itemID`. For more information, see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}}). - The following table lists the properties for metrics: | Property | Type | Description | |--------------|--------|-------------| | `enabled` | boolean | When set to true, the default, enables metrics collection and the metrics endpoint. | | `rules` | array | Named rule to filter metrics. Each rule contains a set of `labels` to filter on and a `regex` expression to apply to the metrics path. | -| `http.increasedCardinality` | boolean | When set to `true` (default), in the Dapr HTTP server, each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption when there many different requested endpoints (such as when interacting with RESTful APIs).
To mitigate high memory usage and egress costs associated with [high cardinality metrics]({{< ref "metrics-overview.md#high-cardinality-metrics" >}}) with the HTTP server, you should set the `metrics.http.increasedCardinality` property to `false`.| -| `http.pathMatching` | array | Paths used for path matching, allowing users to define matching paths in order to manage cardinality. | -| `http.excludeVerbs` | boolean | When set to `true` (default is `false`), the Dapr HTTP server ignores each request HTTP verb when building the method metric label. | +| `http.increasedCardinality` | boolean | When set to true, in the Dapr HTTP server each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption, when there many different requested endpoints (such as when interacting with RESTful APIs).
In Dapr 1.13 the default value is `true` (to preserve the behavior of Dapr <= 1.12), but changes to `false` in Dapr 1.14..| -To further help managing cardinality, path matching allows specified paths matched according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. +To mitigate high memory usage and egress costs associated with [high cardinality metrics]({{< ref "metrics-overview.md#high-cardinality-metrics" >}}) with the HTTP server, you should set the `metrics.http.increasedCardinality` property to `false`. Using rules, you can set regular expressions for every metric exposed by the Dapr sidecar. For example: diff --git a/daprdocs/content/en/operations/observability/metrics/metrics-overview.md b/daprdocs/content/en/operations/observability/metrics/metrics-overview.md index da2ec6fc333..e26453d09f6 100644 --- a/daprdocs/content/en/operations/observability/metrics/metrics-overview.md +++ b/daprdocs/content/en/operations/observability/metrics/metrics-overview.md @@ -70,135 +70,15 @@ spec: enabled: false ``` -## Optimizing HTTP metrics reporting with path matching +## High cardinality metrics -When invoking Dapr using HTTP, metrics are created for each requested method by default. This can result in a high number of metrics, known as high cardinality, which can impact memory usage and CPU. +When invoking Dapr using HTTP, the legacy behavior (and current default as of Dapr 1.13) is to create a separate "bucket" for each requested method. When working with RESTful APIs, this can cause very high cardinality, with potential negative impact on memory usage and CPU. -Path matching allows you to manage and control the cardinality of HTTP metrics in Dapr. This is an aggregation of metrics, so rather than having a metric for each event, you can reduce the number of metrics events and report an overall number. For details on how to set the cardinality in configuration see ({{< ref "configuration-overview.md#metrics" >}}) - -This configuration is opt-in and is enabled via the Dapr configuration `spec.metrics.http.pathMatching`. When defined, it enables path matching, which standardizes specified paths for both metrics paths. This reduces the number of unique metrics paths, making metrics more manageable and reducing resource consumption in a controlled way. - -When `spec.metrics.http.pathMatching` is combined with the `increasedCardinality` flag set to `false`, non-matched paths are transformed into a catch-all bucket to control and limit cardinality, preventing unbounded path growth. Conversely, when `increasedCardinality` is `true` (the default), non-matched paths are passed through as they normally would be, allowing for potentially higher cardinality but preserving the original path data. - -### Examples of Path Matching in HTTP Metrics - -The following examples demonstrate how to use the Path Matching API in Dapr for managing HTTP metrics. On each example, the metrics are collected from 5 HTTP requests to the `/orders` endpoint with different order IDs. By adjusting cardinality and utilizing path matching, you can fine-tune metric granularity to balance detail and resource efficiency. - -These examples illustrate the cardinality of the metrics, highlighting that high cardinality configurations result in many entries, which correspond to higher memory usage for handling metrics. For simplicity, the following example focuses on a single metric: `dapr_http_server_request_count`. - -#### Low cardinality with path matching (Recommendation) - -Configuration: -```yaml -http: - increasedCardinality: false - pathMatching: - - /orders/{orderID} -``` - -Metrics generated: -``` -# matched paths -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/{orderID}",status="200"} 5 -# unmatched paths -dapr_http_server_request_count{app_id="order-service",method="GET",path="",status="200"} 1 -``` - -With low cardinality and path matching configured, you get the best of both worlds by grouping the metrics for the important endpoints without compromising the cardinality. This approach helps avoid high memory usage and potential security issues. - -#### Low cardinality without path matching - -Configuration: - -```yaml -http: - increasedCardinality: false -``` -Metrics generated: -``` -dapr_http_server_request_count{app_id="order-service",method="GET", path="",status="200"} 5 -``` - -In low cardinality mode, the path, which is the main source of unbounded cardinality, is dropped. This results in metrics that primarily indicate the number of requests made to the service for a given HTTP method, but without any information about the paths invoked. - - -#### High cardinality with path matching - -Configuration: -```yaml -http: - increasedCardinality: true - pathMatching: - - /orders/{orderID} -``` - -Metrics generated: -``` -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/{orderID}",status="200"} 5 -``` - -This example results from the same HTTP requests as the example above, but with path matching configured for the path `/orders/{orderID}`. By using path matching, you achieve reduced cardinality by grouping the metrics based on the matched path. - -#### High Cardinality without path matching - -Configuration: -```yaml -http: - increasedCardinality: true -``` - -Metrics generated: -``` -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/1",status="200"} 1 -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/2",status="200"} 1 -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/3",status="200"} 1 -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/4",status="200"} 1 -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/5",status="200"} 1 -``` - -For each request, a new metric is created with the request path. This process continues for every request made to a new order ID, resulting in unbounded cardinality since the IDs are ever-growing. - - -### HTTP metrics exclude verbs - -The `excludeVerbs` option allows you to exclude specific HTTP verbs from being reported in the metrics. This can be useful in high-performance applications where memory savings are critical. - -### Examples of excluding HTTP verbs in metrics - -The following examples demonstrate how to exclude HTTP verbs in Dapr for managing HTTP metrics. - -#### Default - Include HTTP verbs - -Configuration: -```yaml -http: - excludeVerbs: false -``` - -Metrics generated: -``` -dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders",status="200"} 1 -dapr_http_server_request_count{app_id="order-service",method="POST",path="/orders",status="200"} 1 -``` - -In this example, the HTTP method is included in the metrics, resulting in a separate metric for each request to the `/orders` endpoint. - -#### Exclude HTTP verbs - -Configuration: -```yaml -http: - excludeVerbs: true -``` - -Metrics generated: -``` -dapr_http_server_request_count{app_id="order-service",method="",path="/orders",status="200"} 2 -``` - -In this example, the HTTP method is excluded from the metrics, resulting in a single metric for all requests to the `/orders` endpoint. +Dapr 1.13 introduces a new option for the Dapr Configuration resource `spec.metrics.http.increasedCardinality`: when set to `false`, it reports metrics for the HTTP server for each "abstract" method (for example, requesting from a state store) instead of creating a "bucket" for each concrete request path. +The default value of `spec.metrics.http.increasedCardinality` is `true` in Dapr 1.13, to maintain the same behavior as Dapr 1.12 and older. However, the value will change to `false` (low-cardinality metrics by default) in Dapr 1.14. +Setting `spec.metrics.http.increasedCardinality` to `false` is **recommended** to all Dapr users, to reduce resource consumption. The pre-1.13 behavior, which is used when the option is `true`, is considered legacy and is only maintained for users who have special requirements around backwards-compatibility. ## Transform metrics with regular expressions diff --git a/daprdocs/content/en/operations/support/support-release-policy.md b/daprdocs/content/en/operations/support/support-release-policy.md index 1ad4e2b159a..735c1ca1d49 100644 --- a/daprdocs/content/en/operations/support/support-release-policy.md +++ b/daprdocs/content/en/operations/support/support-release-policy.md @@ -45,6 +45,7 @@ The table below shows the versions of Dapr releases that have been tested togeth | Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes | |--------------------|:--------:|:--------|---------|---------|---------|------------| +| June 28th 2024 | 1.13.5
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.5 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.5) | | May 29th 2024 | 1.13.4
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.4 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.4) | | May 21st 2024 | 1.13.3
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) | | April 3rd 2024 | 1.13.2
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) | @@ -137,9 +138,7 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h | 1.10.0 | N/A | 1.10.8 | | 1.11.0 | N/A | 1.11.4 | | 1.12.0 | N/A | 1.12.4 | -| 1.13.0 | N/A | 1.13.2 | -| 1.13.0 | N/A | 1.13.3 | -| 1.13.0 | N/A | 1.13.4 | +| 1.13.0 | N/A | 1.13.5 | ## Upgrade on Hosting platforms diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index 8e949e52f7a..2bc7ca5f984 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -181,6 +181,23 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues. +{{% alert title="Note" color="primary" %}} +Your queue must have the same name as the topic you are publishing to with Dapr. For example, if you are publishing to the pub/sub `"myPubsub"` on the topic `"orders"`, your queue must be named `"orders"`. +If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. +{{% /alert %}} + +### Retry policy and dead-letter queues + +By default, an Azure Service Bus Queue has a dead-letter queue. The messages are retried the amount given for `maxDeliveryCount`. The default `maxDeliveryCount` value defaults to 10, but can be set up to 2000. These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. + +Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr. +1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry. +1. Subscribe to the topic to get the failed messages and deal with them. + +For example, setting up a dead-letter queue `orders-dlq` in the subscription and a resiliency policy lets you subscribe to the topic `orders-dlq` to handle failed messages. + +For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}). + ## Related links - [Basic schema for a Dapr component]({{< ref component-schema >}}) diff --git a/daprdocs/content/en/reference/resource-specs/configuration-schema.md b/daprdocs/content/en/reference/resource-specs/configuration-schema.md index 3507975de98..746d4b5c390 100644 --- a/daprdocs/content/en/reference/resource-specs/configuration-schema.md +++ b/daprdocs/content/en/reference/resource-specs/configuration-schema.md @@ -38,10 +38,6 @@ spec: regex: {} http: increasedCardinality: - pathMatching: - - - - - excludeVerbs: httpPipeline: # for incoming http calls handlers: - name: diff --git a/daprdocs/layouts/shortcodes/dapr-latest-version.html b/daprdocs/layouts/shortcodes/dapr-latest-version.html index 68a8266ae7a..4479012ea65 100644 --- a/daprdocs/layouts/shortcodes/dapr-latest-version.html +++ b/daprdocs/layouts/shortcodes/dapr-latest-version.html @@ -1 +1 @@ -{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.0{{ else }}1.13.4{{ end -}} +{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.5{{ else if .Get "cli" }}1.13.0{{ else }}1.13.5{{ end -}}