mirror of https://github.com/dapr/docs.git
Updated configuration docs
This commit is contained in:
Mark Fussell
parent
aff3230429
commit
3a46c55596
|
|
@ -1,8 +1,140 @@
|
|||
# Configuration
|
||||
# Configurations
|
||||
Dapr configurations are settings that enable you to change the behavior of individual Dapr sidecars or globally on the system services in the Dapr control plane.
|
||||
|
||||
Dapr configuration is a configuration file (in local mode) or a Kubernetes configuration object (in Kubernetes mode). A Dapr sidecar can apply a configuration by using a ```dapr.io/config``` annotation (in Kubernetes mode) or by using a ```--config``` switch with ```dapr run```.
|
||||
An example of a per Dapr sidecar setting is configuring trace settings. An example of a control plane setting is mutual TLS which is a global setting on the Sentry system service.
|
||||
|
||||
A Dapr configuration configures:
|
||||
- [Self hosted sidecar configuration](#Self-hosted-sidecar-configuration)
|
||||
- [Kubernetes sidecar configuration](#Kubernetes-sidecar-configuration)
|
||||
- [Sidecar Configuration settings](#sidecar-configuration-settings)
|
||||
- [Kubernetes control plane configuration](#Kubernetes-control-plane-configuration)
|
||||
- [Control plane configuration settings](#control-plane-configuration-settings)
|
||||
|
||||
* [distributed tracing](../observability/traces.md)
|
||||
* [custom pipeline](../middleware/README.md)
|
||||
## Self hosted sidecar configuration
|
||||
In self hosted mode the Dapr configuration is a configuration file, for example `myappconfig.yaml`. By default Dapr side looks in the `components/` sub-folder under the folder where you run your application for a configuration file.
|
||||
|
||||
A Dapr sidecar can also apply a configuration by using a ```--config``` flag to the file path with ```dapr run``` CLI command.
|
||||
|
||||
## Kubernetes sidecar configuration
|
||||
In Kubernetes mode the Dapr configuration is a Configuration CRD, that is applied to the cluster. For example;
|
||||
|
||||
```cli
|
||||
kubectl apply -f myappconfig.yaml
|
||||
```
|
||||
|
||||
You can use the Dapr CLI to list the Configuration CRDs
|
||||
|
||||
```cli
|
||||
dapr configurations -k
|
||||
```
|
||||
|
||||
A Dapr sidecar can apply a specific configuration by using a ```dapr.io/config``` annotation. For example:
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
dapr.io/id: "nodeapp"
|
||||
dapr.io/port: "3000"
|
||||
dapr.io/config: "myappconfig"
|
||||
```
|
||||
Note: There are more [Kubernetes annotations](../../howto/configure-k8s/readme.md) available to configure the Dapr sidecar on activation by sidecar Injector system service.
|
||||
|
||||
## Sidecar configuration settings
|
||||
|
||||
The following configuration settings can be applied to Dapr sidecars;
|
||||
|
||||
* [Observability distributed tracing](../observability/traces.md)
|
||||
* [Middleware pipelines](../middleware/README.md)
|
||||
|
||||
### Tracing configuration
|
||||
|
||||
The `tracing` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
tracing:
|
||||
enabled: true
|
||||
expandParams: true
|
||||
includeBody: true
|
||||
```
|
||||
|
||||
The following table lists the different properties.
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
enabled | bool | Set tracing to be enabled or disabled
|
||||
expandParams | bool | When true, expands parameters passed to HTTP endpoints
|
||||
includeBody | bool | When true, includes the request body in the tracing event
|
||||
|
||||
### Middleware configuration
|
||||
|
||||
The `middleware` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
```yml
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
- name: uppercase
|
||||
type: middleware.http.uppercase
|
||||
```
|
||||
|
||||
The following table lists the different properties.
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
name | string | name of the middleware component
|
||||
type | string | type of middleware component
|
||||
|
||||
|
||||
|
||||
Example sidecar configuration
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: myappconfig
|
||||
spec:
|
||||
tracing:
|
||||
enabled: true
|
||||
expandParams: true
|
||||
includeBody: true
|
||||
httpPipeline:
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
```
|
||||
|
||||
## Kubernetes control plane configuration
|
||||
There is a single configuration file called `default` installed with the control plane system services that applies global settings.
|
||||
|
||||
## Control plane configuration settings
|
||||
|
||||
A Dapr control plane configuration can configure the following settings:
|
||||
|
||||
* [Mutual TLS](../../howto/configure-mtls/readme.md). Also see [security concepts](../security/readme.md)
|
||||
|
||||
|
||||
Property | Type | Description
|
||||
---- | ------- | -----------
|
||||
enabled | bool | Set mtls to be enabled or disabled
|
||||
allowedClockSkew | string | The extra time to give for certificate expiry based on possible clock skew on a machine. Default is 15 minutes.
|
||||
workloadCertTTL | string | Time a certificate is valid for. Default is 24 hours
|
||||
|
||||
Example control plane configuration
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
mtls:
|
||||
enabled: true
|
||||
allowedClockSkew: 15m
|
||||
workloadCertTTL: 24h
|
||||
```
|
||||
|
||||
## References
|
||||
* [Distributed tracing](../observability/traces.md)
|
||||
* [Middleware pipelines](../middleware/README.md)
|
||||
* [Security](../security/readme.md)
|
||||
* [How-To: Configuring the Dapr sidecar on Kubernetes](../../howto/configure-k8s/readme.md)
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Middleware
|
||||
# Middleware pipeline
|
||||
|
||||
Dapr allows custom processing pipelines to be defined by chaining a series of custom middleware. A request goes through all defined middleware before it's routed to user code, and it goes through the defined middleware (in reversed order) before it's returned to the client, as shown in the following diagram.
|
||||
Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. A request goes through all defined middleware components before it's routed to user code, and then goes through the defined middleware, in reverse order, before it's returned to the client, as shown in the following diagram.
|
||||
|
||||
|
||||
|
||||
## Customize processing pipeline
|
||||
|
||||
When launched, a Dapr sidecar constructs a processing pipeline. The pipeline consists of a [tracing middleware](../observabilty/traces.md) (when tracing is enabled) and a CORS middleware by default. Additional middleware, configured by a Dapr [configuration](../configuration/README.md), are added to the pipeline in the order as they are defined. The pipeline applies to all Dapr API endpoints, including state, pub/sub, direct messaging, bindings and others.
|
||||
When launched, a Dapr sidecar constructs a middleware processing pipeline. By default the pipeline consists of [tracing middleware](../observabilty/traces.md) and CORS middleware. Additional middleware, configured by a Dapr [configuration](../configuration/README.md), can be added to the pipeline in the order they are defined. The pipeline applies to all Dapr API endpoints, including state, pub/sub, service invocation, bindings, security and others.
|
||||
|
||||
> **NOTE:** Dapr provides a **middleware.http.uppercase** middleware that doesn't need any configurations. The middleware changes all texts in a request body to uppercase. You can use it to test/verify if your custom pipeline is in place.
|
||||
> **NOTE:** Dapr provides a **middleware.http.uppercase** pre-registered component that changes all text in a request body to uppercase. You can use it to test/verify if your custom pipeline is in place.
|
||||
|
||||
The following configuration defines a custom pipeline that uses a [OAuth 2.0 middleware](../../howto/authorization-with-oauth/README.md) and an uppercase middleware. In this case, all requests are authorized through the OAuth 2.0 protocol, and transformed to uppercase texts, before they are forwarded to user code.
|
||||
The following configuration example defines a custom pipeline that uses a [OAuth 2.0 middleware](../../howto/authorization-with-oauth/README.md) and an uppercase middleware component. In this case, all requests are authorized through the OAuth 2.0 protocol, and transformed to uppercase text, before they are forwarded to user code.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -20,15 +20,15 @@ metadata:
|
|||
spec:
|
||||
httpPipeline:
|
||||
handlers:
|
||||
- name: middleware.http.oauth2
|
||||
- name: middleware.http.uppercase
|
||||
- name: oauth2
|
||||
type: middleware.http.oauth2
|
||||
- name: uppercase
|
||||
type: middleware.http.uppercase
|
||||
```
|
||||
|
||||
> **NOTE:** in future versions, a middleware can be conditionally applied by matching selectors.
|
||||
|
||||
## Writing a custom middleware
|
||||
|
||||
Dapr uses [FastHTTP](https://github.com/valyala/fasthttp) to implement it's HTTP server. Hence, your HTTP middleware needs to be written as a FastHTTP handler. Your middleware needs to implement a Middleware interface, which defines a **GetHandler** method that returns a **fasthttp.RequestHandler**:
|
||||
Dapr uses [FastHTTP](https://github.com/valyala/fasthttp) to implement it's HTTP server. Hence, your HTTP middleware needs to be written as a FastHTTP handler. Your middleware needs to implement a middleware interface, which defines a **GetHandler** method that returns a **fasthttp.RequestHandler**:
|
||||
|
||||
```go
|
||||
type Middleware interface {
|
||||
|
|
@ -50,4 +50,8 @@ func GetHandler(metadata Metadata) fasthttp.RequestHandler {
|
|||
}
|
||||
```
|
||||
|
||||
Your code should be contributed to the https://github.com/dapr/components-contrib repository, under the */middleware* folder. Then, you'll need to submit another pull request against the https://github.com/dapr/dapr repository to register the new middleware type. You'll need to modify the **Load()** method under https://github.com/dapr/dapr/blob/master/pkg/components/middleware/http/registry.go to register your middleware using the **Register** method.
|
||||
## Submitting middleware components
|
||||
Your middleware component can be contributed to the https://github.com/dapr/components-contrib repository, under the */middleware* folder. Then submit another pull request against the https://github.com/dapr/dapr repository to register the new middleware type. You'll need to modify the **Load()** method under https://github.com/dapr/dapr/blob/master/pkg/components/middleware/http/registry.go to register your middleware using the **Register** method.
|
||||
|
||||
## References
|
||||
* [How-To: Configure API authorization with OAuth](../../howto/authorization-with-oauth/readme.md)
|
||||
|
|
@ -6,9 +6,37 @@ The observability capabilities enable users to monitor the Dapr system services,
|
|||
|
||||
* **[Metrics](./metrics.md)**: are the series of measured values and counts that are collected and stored over time. Dapr metrics provide monitoring and understanding of the behavior of Dapr system services and user apps. For example, the service metrics between Dapr sidecars and user apps show call latency, traffic failures, error rates of requests etc. Dapr system services metrics show side car injection failures, health of the system services including CPU usage, number of actor placement made etc.
|
||||
* **[Logs](./logs.md)**: are records of events that occur occur that can be used to determine failures or other status. Logs events contain warning, error, info and debug messages produced by Dapr system services. Each log event includes metadata such as message type, hostname, component name, App ID, ip address, etc.
|
||||
* **[Distributed tracing](./traces.md)**: is used to profile and monitor Dapr system services and user apps. Distributed tracing helps pinpoint where failures occur and what causes poor performance. Distributed tracing is particularly well-suited to debugging and monitoring distributed software architectures, such as microservices. You can use distributed tracing to help debug and optimize application code. Distributed tracing contains trace spans between the Dapr runtime, Dapr system services, and user apps across process, nodes, network, and security boundaries. It provides a detailed understanding of service invocations (call flows) and service dependencies.
|
||||
* **[Distributed tracing](./traces.md)**: is used to profile and monitor Dapr system services and user apps. Distributed tracing helps pinpoint where failures occur and what causes poor performance. Distributed tracing is particularly well-suited to debugging and monitoring distributed software architectures, such as microservices.
|
||||
|
||||
You can use distributed tracing to help debug and optimize application code. Distributed tracing contains trace spans between the Dapr runtime, Dapr system services, and user apps across process, nodes, network, and security boundaries. It provides a detailed understanding of service invocations (call flows) and service dependencies.
|
||||
|
||||
It is generally recommended to run Dapr in production with tracing.
|
||||
|
||||
* **[Health](./health.md)**: Dapr provides a way for a hosting platform to determine it's health using an HTTP endpoint. With this endpoint, the Dapr process, or sidecar, can be probed to determine its readiness and liveness and action taken accordingly.
|
||||
|
||||
## Open Telemetry
|
||||
Dapr integrates with OpenTelemetry for metrics, logs and tracing. With OpenTelemetry, you can configure various exporters for tracing and metrics based on your environment, whether it is running in the cloud or on-premises.
|
||||
|
||||
## Monitoring tools
|
||||
|
||||
The observability tools listed below are ones that have been tested to work with Dapr.
|
||||
|
||||
### Metrics
|
||||
|
||||
* [How-To: Set up Prometheus and Grafana](../../howto/setup-monitoring-tools/setup-prometheus-grafana.md)
|
||||
* [How-To: Set up Azure Monitor](../../howto/setup-monitoring-tools/setup-azure-monitor.md)
|
||||
|
||||
### Logs
|
||||
|
||||
* [How-To: Set up Fluentd, Elastic search and Kibana in Kubernetes](../../howto/setup-monitoring-tools/setup-fluentd-es-kibana.md)
|
||||
* [How-To: Set up Azure Monitor](../../howto/setup-monitoring-tools/setup-azure-monitor.md)
|
||||
|
||||
### Distributed Tracing
|
||||
|
||||
* [How-To: Set up Zipkin](../../howto/diagnose-with-tracing/zipkin.md)
|
||||
* [How-To: Set up Application Insights](../../howto/diagnose-with-tracing/azure-monitor.md)
|
||||
|
||||
|
||||
## Implementation Status
|
||||
The table below shows the current status of each of the observabilty capabilites for the Dapr runtime and system services. N/A means not applicable.
|
||||
|
||||
|
|
@ -17,22 +45,3 @@ The table below shows the current status of each of the observabilty capabilites
|
|||
|Metrics | Yes | Yes | Yes | Yes | Yes |
|
||||
|Tracing | Yes | N/A | N/A | *Planned* | N/A |
|
||||
|Logs | Yes | Yes | Yes | Yes | Yes |
|
||||
|
||||
## Monitoring tools
|
||||
|
||||
The observability tools listed below are ones that have been tested to work with Dapr.
|
||||
|
||||
### Metrics
|
||||
|
||||
* [Prometheus + Grafana](../../howto/setup-monitoring-tools/setup-prometheus-grafana.md)
|
||||
* [Azure Monitor](../../howto/setup-monitoring-tools/setup-azure-monitor.md)
|
||||
|
||||
### Logs
|
||||
|
||||
* [Fluentd + Elastic Search + Kibana](../../howto/setup-monitoring-tools/setup-fluentd-es-kibana.md)
|
||||
* [Azure Monitor](../../howto/setup-monitoring-tools/setup-azure-monitor.md)
|
||||
|
||||
### Traces
|
||||
|
||||
* [Zipkin](../../howto/diagnose-with-tracing/zipkin.md)
|
||||
* [Application Insights](../../howto/diagnose-with-tracing/azure-monitor.md)
|
||||
|
|
|
|||
|
|
@ -60,6 +60,5 @@ spec:
|
|||
|
||||
## References
|
||||
|
||||
* [How-To: Set up Distributed Tracing with Azure Monitor](../../howto/diagnose-with-tracing/azure-monitor.md)
|
||||
|
||||
* [How-To: Set Up Distributed Tracing with Zipkin](../../howto/diagnose-with-tracing/zipkin.md)
|
||||
* [How-To: Set up Application Insights for distributed tracing](../../howto/diagnose-with-tracing/azure-monitor.md)
|
||||
* [How-To: Set up Zipkin for distributed tracingn](../../howto/diagnose-with-tracing/zipkin.md)
|
||||
|
|
|
|||
|
|
@ -1,17 +1,18 @@
|
|||
# How Tos
|
||||
|
||||
Here you'll find a list of How To guides that walk you through accomplishing specific tasks.
|
||||
Here you'll find a list of "How To" guides that walk you through accomplishing specific tasks.
|
||||
|
||||
## Contents
|
||||
- [Service invocation](#service-invocation)
|
||||
- [State Management](#state-management)
|
||||
- [State management](#state-management)
|
||||
- [Pub/Sub](#pubsub)
|
||||
- [Bindings and Triggers](#bindings-and-triggers)
|
||||
- [Bindings](#bindings-and-triggers)
|
||||
- [Actors](#actors)
|
||||
- [Observerability](#observerability)
|
||||
- [Security](#security)
|
||||
- [Middleware](#middleware)
|
||||
- [Components](#components)
|
||||
- [Hosting Platforms](#hosting-platforms)
|
||||
- [Hosting platforms](#hosting-platforms)
|
||||
- [Developer tooling](#developer-tooling)
|
||||
|
||||
## Service invocation
|
||||
|
|
@ -19,13 +20,9 @@ Here you'll find a list of How To guides that walk you through accomplishing spe
|
|||
* [Invoke other services in your cluster or environment](./invoke-and-discover-services)
|
||||
* [Create a gRPC enabled app, and invoke Dapr over gRPC](./create-grpc-app)
|
||||
|
||||
### Middleware
|
||||
|
||||
* [Authorization with oAuth](./authorization-with-oauth)
|
||||
|
||||
## State Management
|
||||
|
||||
* [Setup Dapr state store](./setup-state-store)
|
||||
* [Setup a state store](./setup-state-store)
|
||||
* [Create a service that performs stateful CRUD operations](./create-stateful-service)
|
||||
* [Query the underlying state store](./query-state-store)
|
||||
* [Create a stateful, replicated service with different consistency/concurrency levels](./stateful-replicated-service)
|
||||
|
|
@ -72,6 +69,10 @@ For Actors How Tos see the SDK documentation
|
|||
* [Configure component secrets using Dapr secret stores](./setup-secret-store)
|
||||
* [Using the Secrets API to get application secrets](./get-secrets)
|
||||
|
||||
## Middleware
|
||||
|
||||
* [Configure API authorization with OAuth](./authorization-with-oauth)
|
||||
|
||||
## Components
|
||||
|
||||
* [Limit components for one or more applications using scopes](./components-scopes)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Authorization with oAuth
|
||||
# Configure API authorization with OAuth
|
||||
|
||||
Dapr OAuth 2.0 [middleware](../../concepts/middleware/README.md) allows you to enable [OAuth](https://oauth.net/2/) authorization on Dapr endpoints for your web APIs, using the [Authorization Code Grant flow](https://tools.ietf.org/html/rfc6749#section-4.1). When the middleware is enabled, any method invocation through Dapr needs to be authorized before getting passed to the user code.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,19 +1,23 @@
|
|||
# Set up distributed tracing with Application insights
|
||||
# Set up Application Insights for distributed tracing
|
||||
|
||||
Dapr integrates with Application Insights through OpenTelemetry's default exporter along with a dedicated agent known as [Local Forwarder](https://docs.microsoft.com/en-us/azure/azure-monitor/app/opencensus-local-forwarder).
|
||||
Dapr integrates with Application Insights through OpenTelemetry's default exporter along with a dedicated agent known as the [Local Forwarder](https://docs.microsoft.com/en-us/azure/azure-monitor/app/opencensus-local-forwarder).
|
||||
|
||||
> Note: Local forwarder is still under preview, but being deprecated. Application insights team recommends to use [Opentelemetry collector](https://github.com/open-telemetry/opentelemetry-collector) (which is in alpha state) for the future so that we're working on moving from local forwarder to [Opentelemetry collector](https://github.com/open-telemetry/opentelemetry-collector).
|
||||
> Note: The local forwarder is still under preview, but being deprecated. The Application Insights team recommends using [Opentelemetry collector](https://github.com/open-telemetry/opentelemetry-collector) (which is in alpha state) for the future so we're working on moving from local forwarder to [Opentelemetry collector](https://github.com/open-telemetry/opentelemetry-collector).
|
||||
|
||||
|
||||
- [How to configure distributed tracing with Application insights](#How-to-configure-distributed-tracing-with-Application-insights)
|
||||
- [Tracing configuration](#Tracing-configuration)
|
||||
|
||||
## How to configure distributed tracing with Application insights
|
||||
|
||||
The following steps will show you how to configure Dapr to send distributed tracing data to Application insights.
|
||||
The following steps show you how to configure Dapr to send distributed tracing data to Application insights.
|
||||
|
||||
### Setup Application insights
|
||||
### Setup Application Insights
|
||||
|
||||
1. First, you'll need an Azure account. Please see instructions [here](https://azure.microsoft.com/free/) to apply for a **free** Azure account.
|
||||
2. Follow instructions [here](https://docs.microsoft.com/en-us/azure/azure-monitor/app/create-new-resource) to create a new Application Insights resource.
|
||||
3. Get Application insights Intrumentation key from your application insights page
|
||||
4. Go to `Configure -> API Access`
|
||||
4. On the Application Insights side menu, go to `Configure -> API Access`
|
||||
5. Click `Create API Key`
|
||||
6. Select all checkboxes under `Choose what this API key will allow apps to do:`
|
||||
- Read telemetry
|
||||
|
|
@ -23,19 +27,20 @@ The following steps will show you how to configure Dapr to send distributed trac
|
|||
|
||||
### Setup the Local Forwarder
|
||||
|
||||
#### Local environment
|
||||
#### Self hosted environment
|
||||
This is for running the local forwarder on your machine.
|
||||
|
||||
1. Run localfowarder
|
||||
1. Run the local fowarder
|
||||
|
||||
```bash
|
||||
docker run -e APPINSIGHTS_INSTRUMENTATIONKEY=<Your Instrumentation Key> -e APPINSIGHTS_LIVEMETRICSSTREAMAUTHENTICATIONAPIKEY=<Your API Key> -d -p 55678:55678 daprio/dapr-localforwarder:0.1-beta1
|
||||
```
|
||||
|
||||
> Note: dapr-localforwarder is created by using [0.1-beta1 release](https://github.com/microsoft/ApplicationInsights-LocalForwarder/releases/tag/v0.1-beta1). If you want to create your own image, please use [this dockerfile](./localforwarder/Dockerfile).
|
||||
> Note: dapr-localforwarder is created by using [0.1-beta1 release](https://github.com/microsoft/ApplicationInsights-LocalForwarder/releases/tag/v0.1-beta1). If you want to create your own image, use [this dockerfile](./localforwarder/Dockerfile).
|
||||
|
||||
1. Copy native.yaml and tracing.yaml to a *components/* sub-folder under the same folder where you run you application.
|
||||
1. Create the following YAML files. Copy the native.yaml component file and tracing.yaml configuration file to the *components/* sub-folder under the same folder where you run your application.
|
||||
|
||||
* native.yaml
|
||||
* native.yaml component
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -51,7 +56,7 @@ spec:
|
|||
value: "localhost:55678"
|
||||
```
|
||||
|
||||
* tracing.yaml
|
||||
* tracing.yaml configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -65,7 +70,7 @@ spec:
|
|||
includeBody: true
|
||||
```
|
||||
|
||||
3. When running in the local mode, you need to launch Dapr with the `--config` parameter:
|
||||
3. When running in the local self hosted mode, you need to launch Dapr with the `--config` parameter:
|
||||
|
||||
```bash
|
||||
dapr run --app-id mynode --app-port 3000 --config ./components/tracing.yaml node app.js
|
||||
|
|
@ -91,7 +96,7 @@ kubectl apply -f ./dapr-localforwarder.yaml
|
|||
|
||||
4. Create the following YAML files
|
||||
|
||||
* native.yaml
|
||||
* native.yaml component
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -107,7 +112,7 @@ spec:
|
|||
value: "<Local forwarder address, e.g. dapr-localforwarder.default.svc.cluster.local:55678>"
|
||||
```
|
||||
|
||||
* tracing.yaml
|
||||
* tracing.yaml configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
|
|
@ -129,7 +134,8 @@ kubectl apply -f native.yaml
|
|||
```
|
||||
|
||||
6. Deploy your app with tracing
|
||||
When running in the Kubernetes model, you need to add a `dapr.io/config` annotation to your container that you want to participate in the distributed tracing, as shown in the following example:
|
||||
|
||||
When running in Kubernetes mode, apply the configuration by adding a `dapr.io/config` annotation to the container that you want to participate in the distributed tracing, as shown in the following example:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
|
@ -148,15 +154,15 @@ spec:
|
|||
dapr.io/config: "tracing"
|
||||
```
|
||||
|
||||
That's it! There's no need include any SDKs or instrument your application code in anyway. Dapr automatically handles distributed tracing for you.
|
||||
That's it! There's no need include any SDKs or instrument your application code. Dapr automatically handles the distributed tracing for you.
|
||||
|
||||
> **NOTE**: You can register multiple exporters at the same time, and tracing logs will be forwarded to all registered exporters.
|
||||
> **NOTE**: You can register multiple exporters at the same time, and the tracing logs are forwarded to all registered exporters.
|
||||
|
||||
Generate some workloads. And after a few minutes, you should see tracing logs appearing in your Application Insights resource. And you can also use **Application map** to examine the topology of your services, as shown below:
|
||||
Deploy and run some applications. After a few minutes, you should see tracing logs appearing in your Application Insights resource. You can also use **Application Map** to examine the topology of your services, as shown below:
|
||||
|
||||
|
||||
|
||||
## Tracing Configuration
|
||||
## Tracing configuration
|
||||
|
||||
The `tracing` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,88 +1,13 @@
|
|||
# Set up distributed tracing with Zipkin
|
||||
# Set up Zipkin for distributed tracing
|
||||
|
||||
Dapr integrates seamlessly with OpenTelemetry for telemetry and tracing. It is recommended to run Dapr with tracing enabled for any production scenario. Since Dapr uses OpenTelemetry, you can configure various exporters for tracing and telemetry data based on your environment, whether it is running in the cloud or on-premises.
|
||||
- [Configure self hosted mode](#Configure-self-hosted-mode)
|
||||
- [Configure Kubernetes](#Configure-Kubernetes)
|
||||
- [Tracing configuration](#Tracing-Configuration)
|
||||
|
||||
## How to configure distributed tracing with Zipkin on Kubernetes
|
||||
|
||||
The following steps will show you how to configure Dapr to send distributed tracing data to Zipkin running as a container in your Kubernetes cluster, and how to view them.
|
||||
## Configure self hosted mode
|
||||
|
||||
### Setup
|
||||
|
||||
First, deploy Zipkin:
|
||||
|
||||
```bash
|
||||
kubectl run zipkin --image openzipkin/zipkin --port 9411
|
||||
```
|
||||
|
||||
Create a Kubernetes Service for the Zipkin pod:
|
||||
|
||||
```bash
|
||||
kubectl expose deploy zipkin --type ClusterIP --port 9411
|
||||
```
|
||||
|
||||
Next, create the following YAML files locally:
|
||||
|
||||
* zipkin.yaml
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: zipkin
|
||||
spec:
|
||||
type: exporters.zipkin
|
||||
metadata:
|
||||
- name: enabled
|
||||
value: "true"
|
||||
- name: exporterAddress
|
||||
value: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"
|
||||
```
|
||||
|
||||
* tracing.yaml
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: tracing
|
||||
spec:
|
||||
tracing:
|
||||
enabled: true
|
||||
expandParams: true
|
||||
includeBody: true
|
||||
```
|
||||
|
||||
Finally, deploy the Dapr configurations:
|
||||
|
||||
```bash
|
||||
kubectl apply -f tracing.yaml
|
||||
kubectl apply -f zipkin.yaml
|
||||
```
|
||||
|
||||
In order to enable this configuration for your Dapr sidecar, add the following annotation to your pod spec template:
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
dapr.io/config: "tracing"
|
||||
```
|
||||
|
||||
That's it! your sidecar is now configured for use with Open Census and Zipkin.
|
||||
|
||||
### Viewing Tracing Data
|
||||
|
||||
To view traces, connect to the Zipkin Service and open the UI:
|
||||
|
||||
```bash
|
||||
kubectl port-forward svc/zipkin 9411:9411
|
||||
```
|
||||
|
||||
On your browser, go to ```http://localhost:9411``` and you should see the Zipkin UI.
|
||||
|
||||
|
||||
|
||||
## How to configure distributed tracing with Zipkin when running in stand-alone mode
|
||||
|
||||
For standalone mode, create an Dapr Configuration CRD file locally and reference it with the Dapr CLI.
|
||||
For self hosted mode, create a Dapr configuration file locally and reference it with the Dapr CLI.
|
||||
|
||||
1. Create the following YAML files:
|
||||
|
||||
|
|
@ -116,7 +41,7 @@ spec:
|
|||
includeBody: true
|
||||
```
|
||||
|
||||
2. Copy *zipkin.yaml* to a *components* folder under the same folder where you run you application.
|
||||
2. Copy `zipkin.yaml` to a `/components` subfolder under the same folder where you run your application.
|
||||
|
||||
3. Launch Zipkin using Docker:
|
||||
|
||||
|
|
@ -124,13 +49,93 @@ spec:
|
|||
docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
```
|
||||
|
||||
3. Launch Dapr with the `--config` param:
|
||||
3. Launch your application with Dapr CLI using the `--config` param:
|
||||
|
||||
```bash
|
||||
dapr run --app-id mynode --app-port 3000 --config ./tracing.yaml node app.js
|
||||
```
|
||||
### Viewing Traces
|
||||
To view traces, in your browser go to http://localhost:9411 and you will see the Zipkin UI.
|
||||
|
||||
## Tracing Configuration
|
||||
## Configure Kubernetes
|
||||
|
||||
The following steps shows you how to configure Dapr to send distributed tracing data to Zipkin running as a container in your Kubernetes cluster, how to view them.
|
||||
|
||||
### Setup
|
||||
|
||||
First, deploy Zipkin:
|
||||
|
||||
```bash
|
||||
kubectl run zipkin --image openzipkin/zipkin --port 9411
|
||||
```
|
||||
|
||||
Create a Kubernetes service for the Zipkin pod:
|
||||
|
||||
```bash
|
||||
kubectl expose deploy zipkin --type ClusterIP --port 9411
|
||||
```
|
||||
|
||||
Next, create the following YAML files locally:
|
||||
|
||||
* zipkin.yaml component
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Component
|
||||
metadata:
|
||||
name: zipkin
|
||||
spec:
|
||||
type: exporters.zipkin
|
||||
metadata:
|
||||
- name: enabled
|
||||
value: "true"
|
||||
- name: exporterAddress
|
||||
value: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"
|
||||
```
|
||||
|
||||
* tracing.yaml configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Configuration
|
||||
metadata:
|
||||
name: tracing
|
||||
spec:
|
||||
tracing:
|
||||
enabled: true
|
||||
expandParams: true
|
||||
includeBody: true
|
||||
```
|
||||
|
||||
Finally, deploy the the Dapr component and configuration files:
|
||||
|
||||
```bash
|
||||
kubectl apply -f tracing.yaml
|
||||
kubectl apply -f zipkin.yaml
|
||||
```
|
||||
|
||||
In order to enable this configuration for your Dapr sidecar, add the following annotation to your pod spec template:
|
||||
|
||||
```yml
|
||||
annotations:
|
||||
dapr.io/config: "tracing"
|
||||
```
|
||||
|
||||
That's it! your sidecar is now configured for use with Open Census and Zipkin.
|
||||
|
||||
### Viewing Tracing Data
|
||||
|
||||
To view traces, connect to the Zipkin Service and open the UI:
|
||||
|
||||
```bash
|
||||
kubectl port-forward svc/zipkin 9411:9411
|
||||
```
|
||||
|
||||
In your browser, go to ```http://localhost:9411``` and you will see the Zipkin UI.
|
||||
|
||||
|
||||
|
||||
## Tracing configuration
|
||||
|
||||
The `tracing` section under the `Configuration` spec contains the following properties:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Set up azure monitor to search logs and collect metrics for Dapr
|
||||
# Set up Azure Monitor to search logs and collect metrics
|
||||
|
||||
This document describes how to enable Dapr metrics and logs with Azure Monitor for Azure Kubernetes Service (AKS).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Set up Fluentd, Elastic search, and Kibana in Kubernetes
|
||||
# Set up Fluentd, Elastic search and Kibana in Kubernetes
|
||||
|
||||
This document descriebs how to install Fluentd, Elastic Search, and Kibana to search logs in Kubernetes
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue