mirror of https://github.com/dapr/docs.git
Merge branch 'v1.16' into add-dapr-agents-improvements
This commit is contained in:
commit
6944df817d
|
|
@ -111,6 +111,138 @@ If you decide to generate trace headers yourself, there are three ways this can
|
|||
|
||||
Read [the trace context overview]({{% ref w3c-tracing-overview %}}) for more background and examples on W3C trace context and headers.
|
||||
|
||||
### Baggage Support
|
||||
|
||||
Dapr supports two distinct mechanisms for propagating W3C Baggage alongside trace context:
|
||||
|
||||
1. **Context Baggage (OpenTelemetry)**
|
||||
- Follows OpenTelemetry conventions with decoded values
|
||||
- Used when working with OpenTelemetry context propagation
|
||||
- Values are stored and transmitted in their original, unencoded form
|
||||
- Recommended for OpenTelemetry integrations and when working with application context
|
||||
|
||||
2. **Header/Metadata Baggage**
|
||||
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting header/metadata baggage
|
||||
- Values remain percent-encoded in transport as required by the W3C Baggage spec
|
||||
- Values stay encoded when inspecting raw headers/metadata
|
||||
- Only OpenTelemetry APIs will decode the values
|
||||
- Example: Use `serverNode=DF%2028` (not `serverNode=DF 28`) when setting header baggage
|
||||
|
||||
For security purposes, context baggage and header baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties.
|
||||
|
||||
#### Using Baggage with Dapr
|
||||
|
||||
You can propagate baggage using either mechanism, depending on your use case.
|
||||
|
||||
1. **In your application code**: Set the baggage in the context before making a Dapr API call
|
||||
2. **When calling Dapr**: Pass the context to any Dapr API call
|
||||
3. **Inside Dapr**: The Dapr runtime automatically picks up the baggage
|
||||
4. **Propagation**: Dapr automatically propagates the baggage to downstream services, maintaining the appropriate encoding for each mechanism
|
||||
|
||||
Here are examples of both mechanisms:
|
||||
|
||||
**1. Using Context Baggage (OpenTelemetry)**
|
||||
|
||||
When using OpenTelemetry SDK:
|
||||
|
||||
{{< tabpane text=true >}}
|
||||
|
||||
{{% tab header="Go" %}}
|
||||
|
||||
```go
|
||||
import otelbaggage "go.opentelemetry.io/otel/baggage"
|
||||
|
||||
// Set baggage in context (values remain unencoded)
|
||||
baggage, err = otelbaggage.Parse("userId=cassie,serverNode=DF%2028")
|
||||
...
|
||||
ctx := otelbaggage.ContextWithBaggage(t.Context(), baggage)
|
||||
)
|
||||
|
||||
// Pass this context to any Dapr API call
|
||||
client.InvokeMethodWithContent(ctx, "serviceB", ...)
|
||||
```
|
||||
|
||||
**2. Using Header/Metadata Baggage**
|
||||
|
||||
When using gRPC metadata:
|
||||
```go
|
||||
import "google.golang.org/grpc/metadata"
|
||||
|
||||
// Set URL-encoded baggage in context
|
||||
ctx = metadata.AppendToOutgoingContext(ctx,
|
||||
"baggage", "userId=cassie,serverNode=DF%2028",
|
||||
)
|
||||
|
||||
// Pass this context to any Dapr API call
|
||||
client.InvokeMethodWithContent(ctx, "serviceB", ...)
|
||||
```
|
||||
|
||||
**3. Receiving Baggage in Target Service**
|
||||
|
||||
In your target service, you can access the propagated baggage:
|
||||
|
||||
```go
|
||||
// Using OpenTelemetry (values are automatically decoded)
|
||||
import "go.opentelemetry.io/otel/baggage"
|
||||
|
||||
bag := baggage.FromContext(ctx)
|
||||
userID := bag.Member("userId").Value() // "cassie"
|
||||
```
|
||||
|
||||
```go
|
||||
// Using raw gRPC metadata (values remain percent-encoded)
|
||||
import "google.golang.org/grpc/metadata"
|
||||
|
||||
md, _ := metadata.FromIncomingContext(ctx)
|
||||
if values := md.Get("baggage"); len(values) > 0 {
|
||||
// values[0] contains the percent-encoded string you set: "userId=cassie,serverNode=DF%2028"
|
||||
// Remember: You must URL encode special characters when setting baggage
|
||||
|
||||
// To decode the values, use OpenTelemetry APIs:
|
||||
bag, err := baggage.Parse(values[0])
|
||||
...
|
||||
userID := bag.Member("userId").Value() // "cassie"
|
||||
}
|
||||
```
|
||||
|
||||
*HTTP Example (URL-encoded):*
|
||||
```bash
|
||||
curl -X POST http://localhost:3500/v1.0/invoke/serviceB/method/hello \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "baggage: userID=cassie,serverNode=DF%2028" \
|
||||
-d '{"message": "Hello service B"}'
|
||||
```
|
||||
|
||||
*gRPC Example (URL-encoded):*
|
||||
```go
|
||||
ctx = grpcMetadata.AppendToOutgoingContext(ctx,
|
||||
"baggage", "userID=cassie,serverNode=DF%2028",
|
||||
)
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabpane >}}
|
||||
|
||||
#### Common Use Cases
|
||||
|
||||
Baggage is useful for:
|
||||
- Propagating user IDs or correlation IDs across services
|
||||
- Passing tenant or environment information
|
||||
- Maintaining consistent context across service boundaries
|
||||
- Debugging and troubleshooting distributed transactions
|
||||
|
||||
#### Best Practices
|
||||
|
||||
1. **Choose the Right Mechanism**
|
||||
- Use Context Baggage when working with OpenTelemetry
|
||||
- Use Header Baggage when working directly with HTTP/gRPC
|
||||
|
||||
2. **Security Considerations**
|
||||
- Be mindful that baggage is propagated across service boundaries
|
||||
- Don't include sensitive information in baggage
|
||||
- Remember that context and header baggage remain separate
|
||||
|
||||
## Related Links
|
||||
|
||||
- [Observability concepts]({{% ref observability-concept.md %}})
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ When a request arrives without a trace ID, Dapr creates a new one. Otherwise, it
|
|||
These are the specific trace context headers that are generated and propagated by Dapr for HTTP and gRPC.
|
||||
|
||||
{{< tabpane text=true >}}
|
||||
<!-- HTTP -->
|
||||
|
||||
{{% tab "HTTP" %}}
|
||||
|
||||
Copy these headers when propagating a trace context header from an HTTP response to an HTTP request:
|
||||
|
|
@ -73,14 +73,67 @@ tracestate: congo=t61rcWkgMzE
|
|||
|
||||
[Learn more about the tracestate fields details](https://www.w3.org/TR/trace-context/#tracestate-header).
|
||||
|
||||
**Baggage Support**
|
||||
|
||||
Dapr supports [W3C Baggage](https://www.w3.org/TR/baggage/) for propagating key-value pairs alongside trace context through two distinct mechanisms:
|
||||
|
||||
1. **Context Baggage (OpenTelemetry)**
|
||||
- Follows OpenTelemetry conventions with decoded values
|
||||
- Used when propagating baggage through application context
|
||||
- Values are stored in their original, unencoded form
|
||||
- Example of how it would be printed with OpenTelemetry APIs:
|
||||
```
|
||||
baggage: userId=cassie,serverNode=DF 28,isVIP=true
|
||||
```
|
||||
|
||||
2. **HTTP Header Baggage**
|
||||
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting header baggage
|
||||
- Values remain percent-encoded in HTTP headers as required by the W3C Baggage spec
|
||||
- Values stay encoded when inspecting raw headers in Dapr
|
||||
- Only OpenTelemetry APIs like `otelbaggage.Parse()` will decode the values
|
||||
- Example (note the URL-encoded space `%20`):
|
||||
```bash
|
||||
curl -X POST http://localhost:3500/v1.0/invoke/serviceB/method/hello \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "baggage: userId=cassie,serverNode=DF%2028,isVIP=true" \
|
||||
-d '{"message": "Hello service B"}'
|
||||
```
|
||||
|
||||
For security purposes, context baggage and header baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties in each domain.
|
||||
|
||||
Multiple baggage headers are supported and will be combined according to the W3C specification. Dapr automatically propagates baggage across service calls while maintaining the appropriate encoding for each domain.
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
|
||||
<!-- gRPC -->
|
||||
{{% tab "gRPC" %}}
|
||||
|
||||
In the gRPC API calls, trace context is passed through `grpc-trace-bin` header.
|
||||
|
||||
**Baggage Support**
|
||||
|
||||
Dapr supports [W3C Baggage](https://www.w3.org/TR/baggage/) for propagating key-value pairs alongside trace context through two distinct mechanisms:
|
||||
|
||||
1. **Context Baggage (OpenTelemetry)**
|
||||
- Follows OpenTelemetry conventions with decoded values
|
||||
- Used when propagating baggage through gRPC context
|
||||
- Values are stored in their original, unencoded form
|
||||
- Example of how it would be printed with OpenTelemetry APIs:
|
||||
```
|
||||
baggage: userId=cassie,serverNode=DF 28,isVIP=true
|
||||
```
|
||||
|
||||
2. **gRPC Metadata Baggage**
|
||||
- You must URL encode special characters (for example, `%20` for spaces, `%2F` for slashes) when setting metadata baggage
|
||||
- Values remain percent-encoded in gRPC metadata
|
||||
- Example (note the URL-encoded space `%20`):
|
||||
```
|
||||
baggage: userId=cassie,serverNode=DF%2028,isVIP=true
|
||||
```
|
||||
|
||||
For security purposes, context baggage and metadata baggage are strictly separated and never merged between domains. This ensures that baggage values maintain their intended format and security properties in each domain.
|
||||
|
||||
Multiple baggage metadata entries are supported and will be combined according to the W3C specification. Dapr automatically propagates baggage across service calls while maintaining the appropriate encoding for each domain.
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabpane >}}
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ spec:
|
|||
- name: cacheTTL
|
||||
value: 10m
|
||||
# - name: apiType # Optional
|
||||
# value: `azure`
|
||||
# value: 'azure'
|
||||
# - name: apiVersion # Optional
|
||||
# value: '2025-01-01-preview'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -95,6 +95,7 @@ The above example uses secrets as plain strings. It is recommended to use a [sec
|
|||
| subscribeMode | N | Subscription mode indicates the cursor persistence, durable subscription retains messages and persists the current position. Default: `"durable"` | `"durable"`, `"non_durable"` |
|
||||
| partitionKey | N | Sets the key of the message for routing policy. Default: `""` | |
|
||||
| `maxConcurrentHandlers` | N | Defines the maximum number of concurrent message handlers. Default: `100` | `10`
|
||||
| replicateSubscriptionState | N | Enable replication of subscription state across geo-replicated Pulsar clusters. Default: `"false"` | `"true"`, `"false"` |
|
||||
|
||||
### Authenticate using Token
|
||||
|
||||
|
|
|
|||
|
|
@ -66,6 +66,8 @@ spec:
|
|||
value: {podName}
|
||||
- name: heartBeat
|
||||
value: 10s
|
||||
- name: publishMessagePropertiesToMetadata
|
||||
value: "true"
|
||||
```
|
||||
|
||||
{{% alert title="Warning" color="warning" %}}
|
||||
|
|
@ -102,7 +104,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
|
|||
| clientKey | Required for using TLS | TLS client key in PEM format. Must be used with `clientCert`. Can be `secretKeyRef` to use a secret reference. | `"-----BEGIN RSA PRIVATE KEY-----\n<base64-encoded PKCS8>\n-----END RSA PRIVATE KEY-----"`
|
||||
| clientName | N | This RabbitMQ [client-provided connection name](https://www.rabbitmq.com/connections.html#client-provided-names) is a custom identifier. If set, the identifier is mentioned in RabbitMQ server log entries and management UI. Can be set to {uuid}, {podName}, or {appID}, which is replaced by Dapr runtime to the real value. | `"app1"`, `{uuid}`, `{podName}`, `{appID}`
|
||||
| heartBeat | N | Defines the heartbeat interval with the server, detecting the aliveness of the peer TCP connection with the RabbitMQ server. Defaults to `10s` . | `"10s"`
|
||||
|
||||
| `publishMessagePropertiesToMetadata` | N | Whether to publish AMQP message properties (headers, message ID, etc.) to the metadata. | "true", "false"
|
||||
|
||||
## Communication using TLS
|
||||
|
||||
|
|
@ -475,6 +477,11 @@ spec:
|
|||
singleActiveConsumer: "true"
|
||||
```
|
||||
|
||||
## Publishing message properties to metadata
|
||||
|
||||
To enable [message properties](https://www.rabbitmq.com/docs/publishers#message-properties) being published in the metadata, set the `publishMessagePropertiesToMetadata` field to `"true"` in the component spec.
|
||||
This will include properties such as message ID, timestamp, and headers in the metadata of the published message.
|
||||
|
||||
## Related links
|
||||
|
||||
- [Basic schema for a Dapr component]({{% ref component-schema %}}) in the Related links section
|
||||
|
|
|
|||
|
|
@ -10,4 +10,11 @@
|
|||
indexName: 'daprdocs',
|
||||
});
|
||||
</script>
|
||||
{{ end }}
|
||||
|
||||
<!-- Start of Reo Javascript -->
|
||||
<script type="text/javascript">
|
||||
!function(){var e,t,n;e="5901cc15fcf7e10",t=function(){Reo.init({clientID:"5901cc15fcf7e10"})},(n=document.createElement("script")).src="https://static.reo.dev/"+e+"/reo.js",n.defer=!0,n.onload=t,document.head.appendChild(n)}();
|
||||
</script>
|
||||
<!-- End of Reo Javascript -->
|
||||
|
||||
{{ end }}
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 5afb5a210b2ec857f43afdfe5deba365a6eb4fb5
|
||||
Subproject commit 241a646a2037d4e91d3192dcbaf1f128b15de185
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 682f93206d40ab83589fccb58afe8f409b7d38c1
|
||||
Subproject commit 6dd434913b6fb41f6ede006c64c01a35a02c458f
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit afa2feeacef73e5598fab88c605d61f5998efa86
|
||||
Subproject commit 3bb91e505e34ef3b7bc3325be853de8d0491c431
|
||||
Loading…
Reference in New Issue