mirror of https://github.com/dapr/docs.git
resolve merge conflicts
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
Hannah Hunter
commit
ad078b7185
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -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/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -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/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -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<OrderPayload, OrderResult>
|
|||
#### `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/)
|
||||
- [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/)
|
||||
- [Apache Maven](https://maven.apache.org/install.html) version 3.x.
|
||||
<!-- IGNORE_LINKS -->
|
||||
- [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/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -1073,7 +1078,6 @@ The `Activities` directory holds the four workflow activities used by the workfl
|
|||
<!-- Go -->
|
||||
{{% 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/`).
|
||||
|
||||
<img src="/images/workflow-trace-spans-zipkin.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -111,15 +111,6 @@ metrics:
|
|||
latencyDistributionBuckets: []
|
||||
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 this 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" >}})
|
||||
|
|
@ -135,7 +126,7 @@ The following table lists the properties for metrics:
|
|||
| `http.pathMatching` | array | Array of paths for path matching, allowing users to define matching paths 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. |
|
||||
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -70,133 +70,11 @@ 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.
|
||||
|
||||
## Configuring custom latency histogram buckets
|
||||
|
||||
|
|
|
|||
|
|
@ -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</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>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</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>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</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>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</br> | 1.13.0 | Java 1.11.0 </br>Go 1.10.0 </br>PHP 1.2.0 </br>Python 1.13.0 </br>.NET 1.13.0 </br>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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 >}})
|
||||
|
|
|
|||
|
|
@ -41,10 +41,6 @@ spec:
|
|||
- <BUCKET-VALUE-MS-1>
|
||||
http:
|
||||
increasedCardinality: <TRUE-OR-FALSE>
|
||||
pathMatching:
|
||||
- <PATH-A>
|
||||
- <PATH-B>
|
||||
excludeVerbs: <TRUE-OR-FALSE>
|
||||
httpPipeline: # for incoming http calls
|
||||
handlers:
|
||||
- name: <HANDLER-NAME>
|
||||
|
|
|
|||
|
|
@ -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 -}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue