可观测性

在构建应用程序时，了解系统的行为方式是运维它的重要部分——这包括能够观察应用程序的内部调用、衡量其性能并在问题发生时能够立即找到问题。这对任何系统来说都是具有挑战性的，对于由多个微服务组成的分布式系统更是如此，其中由多个调用组成的流可能在一个微服务中开始，但在另一个微服务中继续调用。可观测性在生产环境中至关重要，在开发过程中对于了解瓶颈、提高性能和跨微服务执行基本调试也很有用。

虽然可以从底层基础架构中收集有关应用程序的一些数据（例如内存消耗、CPU 使用情况），但必须从应用程序感知层收集其他有意义的信息——该层可以显示如何执行一系列重要的调用跨微服务。这通常意味着开发人员必须为此添加一些代码来检测应用程序。通常，检测代码只是将收集到的数据（例如追踪和指标）发送到外部监控工具或服务，以帮助存储、可视化和分析这些信息。

由于这部分代码并不是应用程序的核心逻辑，所以这自然成为了开发人员的另一个负担，有时需要了解监控工具的 API，使用额外的 SDK 等。这种工具也可能会增加应用程序的可移植性挑战。应用程序可能需要不同的工具，具体取决于应用程序的部署环境。例如，不同的云提供商提供不同的监控解决方案，本地部署可能需要本地解决方案。

用于获得可观测性的系统信息被称为telemetry（遥测），它可以分为四大类。

1. Distributed tracing（分布式追踪） 提供了对参与分布式业务通信的服务之间流量的洞察力。
2. Metrics（指标） 提供了对服务性能及其资源消耗的洞察力。
3. Logging（日志） 提供了对代码如何执行以及是否发生错误的洞察力。
4. Health（健康） 端点提供了对服务可用性的洞察力。

Dapr 可观测性构件将可观测性与应用解耦，它自动捕捉由构成 Dapr 控制平面的 Dapr sidecar 和 Dapr 系统服务产生的流量。该模块将跨越多个服务的单个操作的流量进行关联。它还暴露了性能指标、资源利用率和系统的健康状况。遥测数据以开放标准的格式发布，使信息能够被输入你选择的监控后端。在那里，这些信息可以被可视化、查询和分析。

由于 Dapr 进行了抽象，所以应用程序不知道可观测性是如何实现的。不需要开发者关心如何去实现这部分与核心业务逻辑无关的代码，Dapr 允许开发者专注于构建业务逻辑，而不是观察能力的建设。观察力是在 Dapr 系统层面上配置的，并且在不同的服务中是一致的，即使是由不同的团队创建，并使用不同的技术栈构建。

如何工作

Dapr 的 sidecar 架构实现了内置的可观测性功能，当服务进行通信时，Dapr sidecars 拦截流量并提取追踪、指标和日志信息，遥测数据以开放标准格式进行发布，默认 Dapr 支持 OpenTelemetry 和 Zipkin。

Dapr 提供 collectors 收集器，可以将遥测数据发布到不同的后端监控工具，这些工具将 Dapr 遥测数据呈现出来，用于分析和查询。图 10-1 显示了 Dapr 的可观察性架构。

• 服务 A 调用服务 B 的一个操作，该调用从服务 A 的 Dapr sidecar 被路由到服务 B 的 sidecar。
• 当服务 B 完成操作时，响应会通过 Dapr sidecar 被送回服务 A。它们收集并发布每个请求和响应的所有可用遥测数据。
• 配置的收集器摄取遥测数据并将其发送到监控后端。

不过需要注意的是添加可观测性的支持不同于配置其他 Dapr 构建块，比如前面我们介绍的发布订阅或者状态管理这些组件，我们不需要引用构建块了，而是添加收集器和监控后端，上图显示我们可以配置多个与不同监控后端集成的收集器。

下面我们来分别对可观测性的几个遥测类型进行说明。

分布式追踪

分布式追踪提供了对分布式应用中跨服务流动流量的洞察力。交换的请求和响应信息的日志是排除问题的重要信息来源，比较困难的是把属于同一业务事务的消息整合起来。

Dapr 使用 W3C Trace Context 这个统一的标准来关联相关信息，它将相同的上下文信息注入到一次完整的请求和响应中。

上图显示了一个 W3C Trace Context 标准的示例：

• 服务 A 调用服务 B 上的操作。当服务 A 开始调用时，Dapr 创建一个唯一的 trace context 并将其注入到请求中。
• 服务 B 接收请求并调用服务 C 上的操作。Dapr 检测到传入请求包含 trace context 并通过将其注入到服务 C 的传出请求中来传播它。
• 服务 C 接收请求并处理它。Dapr 检测到传入的请求包含 trace context，并通过将其注入到传出响应中返回给服务 B 来传播它。
• 服务 B 接收响应并处理它。然后它创建一个新的响应并通过将其注入到传出响应中来传播 trace context 并返回到服务 A。

一组属于一起的请求和响应就称为 trace（追踪），如下图所示：

注意查看上图 trace 是如何代表一个发生在许多服务中的独特应用事务的。一个 trace 是一系列 spans 集合组成的，每个 span 代表一个单一的操作或在 trace 中完成的工作单位。Spans 是在实现单一事务的服务之间发送的请求和响应。

接下来我们来讨论如何通过将遥测数据发布到对应的监控后端。

使用 Zipkin

Zipkin 是一个开源的分布式追踪系统，它可以摄取和可视化遥测数据。Dapr 为 Zipkin 提供了默认支持。

当 Dapr 在自托管模式下初始化 (dapr init) 时，多个容器会部署到本地 Docker，可以运行 docker ps 命令查看本地运行的所有容器，确保 Zipkin 容器已启动并正在运行，并记下它正在运行的端口（默认为 9411）。

如果没有 Zipkin 容器服务运行，可以使用下面的命令来进行启动：

➜  docker run --name dapr_zipkin -d -p 9411:9411 openzipkin/zipkin

此时其实我们即可在浏览器中通过 http://localhost:9411 访问到 Zipkin 的 Web 页面，在 Dashboard 中我们可以搜索查看已通过 Dapr 可观测性构建块记录的遥测数据。

在搜索结果中点击 SHOW 按钮即可查看详细的遥测数据。

我们可以发现在本地自拓管模式下面并没有做任何的关于 Zipkin 的配置，当有服务请求经过了 Dapr sidecar 过后，Zipkin 中就有了对应的遥测数据了，这是因为自拓管模式下面默认就启用了 Zipkin 来收集遥测数据。相关的配置位于 $HOME/.dapr/config.yaml，内容如下所示：

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: daprConfig
spec:
  tracing:
    samplingRate: '1'
    zipkin:
      endpointAddress: http://localhost:9411/api/v2/spans

所以如果是在 Kubernetes 模式下面要启用 Zipkin 作为 tracing 后端，则需要单独创建 Configuration 对象才行。

首先，必须使用 Dapr 配置文件为 Dapr 运行时启用 tracing。下面是一个名为 dapr-config.yaml 的配置文件示例，它启用了 tracing：

# dapr-config.yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
spec:
  tracing:
    samplingRate: '1'
    zipkin:
      endpointAddress: 'http://zipkin.default.svc.cluster.local:9411/api/v2/spans'

可以看到该配置文件和本地的配置几乎一致，唯一不同的就是 zipkin.endpointAddress 的地址不同。其中的 samplingRate 属性指定了用于发布追踪的间隔时间，这个值必须在 0（禁止追踪）和 1（每条追踪都被发布）之间。例如，值为 0.5 时，则表示每隔一段时间就发布一次 trace，这样就大大减少了发布流量。我们这里的 zipkin.endpointAddress 指向 Kubernetes 集群中运行的 Zipkin 服务器，Zipkin 的默认端口是 9411。直接应用该资源对象即可：

➜  kubectl apply -f dapr-config.yaml

当然还需要手动部署 Zipkin 服务，对应的资源清单文件如下所示：

# zipkin.yaml
kind: Deployment
apiVersion: apps/v1
metadata:
  name: zipkin
  namespace: default
  labels:
    service: zipkin
spec:
  selector:
    matchLabels:
      service: zipkin
  template:
    metadata:
      labels:
        service: zipkin
    spec:
      containers:
        - name: zipkin
          image: openzipkin/zipkin-slim
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 9411
              protocol: TCP
---
kind: Service
apiVersion: v1
metadata:
  name: zipkin
  namespace: default
  labels:
    service: zipkin
spec:
  type: NodePort
  ports:
    - port: 9411
      targetPort: 9411
      nodePort: 32411
      protocol: TCP
      name: zipkin
  selector:
    service: zipkin

这里我们使用的 openzipkin/zipkin-slim 容器镜像，Zipkin Service 暴露了 Zipkin Web 前端，可以通过 32411 端口来进行访问。同样直接应用上面的资源清单：

➜  kubectl apply -f zipkin.yaml

部署完成后可以查看 Pod 状态了解应用是否部署成功：

➜  kubectl get pods -l service=zipkin
NAME                     READY   STATUS    RESTARTS   AGE
zipkin-f5c696fb7-94mqz   1/1     Running   0          3m9s
➜  kubectl get svc -l service=zipkin
NAME     TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
zipkin   NodePort   10.102.75.84   <none>        9411:32411/TCP   30s

部署成功后可以通过 http:<node-ip>:32411 来访问 Zipkin Web 页面。

接下来我们就可以发布遥测数据了，需要注意的是我们需要在每个 Dapr sidecar 在启动时发出遥测数据，为此需要为应用添加一个 dapr.io/config 注解。

同样这里我们还是以 quickstarts 示例进行说明，定位到 tutorials/distributed-calculator 目录下面：

➜  git clone [-b <dapr_version_tag>] https://github.com/dapr/quickstarts.git
➜  cd tutorials/distributed-calculator

该示例是一个分布式计算器，展示了 Dapr 的方法调用和状态持久化功能，其中每个操作都由用不同语言/框架编写的服务提供支持:

• Addition: Go mux application
• Multiplication: Python flask application
• Division: Node Express application
• Subtraction: .NET Core application

前端应用由一个服务端和一个用 React 编写的客户端组成，源码地址：React calculator 。

上图为该示例应用各个组件的组成和服务架构。

我们可以随便查看一个微服务的部署清单，位于 deploy/ 目录下面，比如 go-adder.yaml：

# go-adder.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: addapp
  labels:
    app: add
spec:
  replicas: 1
  selector:
    matchLabels:
      app: add
  template:
    metadata:
      labels:
        app: add
      annotations:
        dapr.io/enabled: 'true'
        dapr.io/app-id: 'addapp'
        dapr.io/app-port: '6000'
        dapr.io/config: 'appconfig'
    spec:
      containers:
        - name: add
          image: ghcr.io/dapr/samples/distributed-calculator-go:latest
          env:
            - name: APP_PORT
              value: '6000'
          ports:
            - containerPort: 6000
          imagePullPolicy: Always

上面的资源清单中我们通过 dapr.io/config 注解指定了使用 appconfig 这个配置文件，该配置文件中使用了 Zipkin 服务来获取遥测数据，其他微服务中也使用了该注解，所以当应用部署完成后，Zipkin 就能获取到相应的遥测数据。

需要注意 dapr.io/config 后面指定的 Configuration 对象需要和当前应用位于同一个命名空间之下。

直接部署该示例应用：

➜  kubectl apply -f deploy/

部署完成后我们可以通过 dapr configurations 命令查看当前集群中的所有配置信息：

➜  dapr configurations -k -A
  NAMESPACE  NAME       TRACING-ENABLED  METRICS-ENABLED  AGE  CREATED
  default    appconfig  true             true             1m   2022-09-20 17:01.21

同样在 Dashboard 中也可以看到该配置信息：

应用部署完成后查看 Pod 的状态：

➜  kubectl get pods
NAME                                    READY   STATUS    RESTARTS         AGE
addapp-84c9764fdb-72mxf                 2/2     Running   0                74m
calculator-front-end-59cbb6658c-rbctf   2/2     Running   0                74m
divideapp-8476b7fbb6-kr8dr              2/2     Running   0                74m
multiplyapp-7c45fbbf99-hrmff            2/2     Running   0                74m
subtractapp-58645db87-25tg9             2/2     Running   0                62m
➜  kubectl get svc
NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                               AGE
addapp-dapr                 ClusterIP      None             <none>         80/TCP,50001/TCP,50002/TCP,9090/TCP   8m29s
calculator-front-end        LoadBalancer   10.110.177.32    192.168.0.54   80:31701/TCP                          8m29s
calculator-front-end-dapr   ClusterIP      None             <none>         80/TCP,50001/TCP,50002/TCP,9090/TCP   8m29s
divideapp-dapr              ClusterIP      None             <none>         80/TCP,50001/TCP,50002/TCP,9090/TCP   8m29s
multiplyapp-dapr            ClusterIP      None             <none>         80/TCP,50001/TCP,50002/TCP,9090/TCP   8m29s
subtractapp-dapr            ClusterIP      None             <none>         80/TCP,50001/TCP,50002/TCP,9090/TCP   8m29s
zipkin                      NodePort       10.108.46.223    <none>         9411:32411/TCP                        16m

部署完成后我们可以通过 calculator-front-end 这个 LoadBalancer 类型的 Service 去访问计算器的前端应用，我们这里分配的 EXTERNAL-IP 地址为 192.168.0.54。

打开浏览器的控制台窗口(使用 F12 键) ，查看在使用计算器时生成的日志。请注意，每次单击按钮时，都会看到表示状态持久性的日志:

Rehydrating State:
{total: "21", next: "2", operation: "x"}

还要注意，每次输入一个完整的方程式(例如 126 ÷ 3 =) ，日志都会指示对服务的调用:

Calling divide service

客户端代码调用 Express 服务器，后者将调用通过 Dapr 路由到后端服务。在这种情况下，在 nodejs 应用程序上调用 divide 端点。

当我们操作应用的时候，后面就有网络请求产生，也就有了微服务之间的调用，所以此时就会参数对应的 trace 遥测数据，我们可以前往 Zipkin 查询下数据。

点击 SHOW 就可以看到详细的遥测数据。

同样的除了 Zipkin，其他监视后端软件也可引入 Zipkin 格式的遥测，比如 Jaeger，Jaeger 是由 Uber 创建的开源追踪系统。它用于跟踪分布式服务之间的事务，并对复杂的微服务环境进行故障排除，又比如 New Relic 是一个全堆栈可观测性平台，它可以链接来自分散应用程序的相关数据，以提供系统的完整图片 要试用它们，只需要在 Dapr 配置文件中指定一个指向 Jaeger 或 New Relic 服务器的 endpointAddress 即可。下面是配置 Dapr 以将遥测发送到 Jaeger 服务器的配置文件示例。 Jaeger 的 URL 与 Zipkin 的 URL 相同。 唯一的区别是服务器运行的端口号：

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: dapr-config
  namespace: default
spec:
  tracing:
    samplingRate: '1'
    zipkin:
      endpointAddress: 'http://localhost:9415/api/v2/spans'

同样如果要使用 New Relic，则需要将 endpointAddress 指定为 New Relic API 的地址。

指标

指标可让你深入了解应用性能和资源消耗情况，在后台，Dapr 发出各种系统和运行时指标的集合。Dapr 使用 Prometheus 作为指标标准，Dapr 和系统服务在端口 9090 上暴露指标数据。Prometheus scraper 以预定义的时间间隔调用该接口收集指标数据，scraper 将指标值发送到监控后端，如下所示：

你可能想知道指标抓取器如何知道在何处收集指标，Prometheus 可与内置在目标部署环境中的发现机制集成。例如在 Kubernetes 中运行时，Prometheus 可与 Kubernetes API 集成，以查找环境中运行的所有可用 Kubernetes 资源。

Dapr 为 Dapr 系统服务及其运行时生成了大量指标，如下表格所示：

在运行时，可以通过在 Dapr 命令中包含 --enable-metrics=false 的参数来禁用指标收集，也可使用 --metrics-port 9090 参数更改指标端点的默认端口。

你还可以通过为应用程序部署设置 dapr.io/enable-metrics: "false" 注解来禁用特定应用程序的指标导出器，禁用指标导出器后，daprd 将不会打开指标监听端口。以下示例显示使用指定为 9090 的端口显式启用指标。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodeapp
spec:
  selector:
    matchLabels:
      app: node
  template:
    metadata:
      labels:
        app: node
      annotations:
        dapr.io/enabled: 'true'
        dapr.io/app-id: 'nodeapp'
        dapr.io/app-port: '3000'
        dapr.io/enable-metrics: 'true'
        dapr.io/metrics-port: '9090'
    spec:
      containers:
        - name: node
          image: dapriosamples/hello-k8s-node:latest
          ports:
            - containerPort: 3000
          imagePullPolicy: Always

你也可以使用 Dapr 配置文件的方式启用或禁用运行时指标收集：

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: dapr-config
spec:
  tracing:
    samplingRate: '1'
  metric:
    enabled: false # 禁用指标

Prometheus 抓取器收集指标并将其发布到监视后端后，此时我们就可以使用 Grafana 来创建仪表盘，包括监控 Dapr 系统服务和 sidecar，我们可以直接导入 Dapr 提供的仪表盘模板来监控 Dapr，地址 https://github.com/dapr/dapr/tree/master/grafana，其中包含 3 个仪表盘。

• Dapr 系统服务状态 - dapr-operator、dapr-sidecar-injector、dapr-sentry 和 dapr-placement
• Dapr 边车仪表板 - 显示 Dapr sidecar 状态，包括 sidecar 运行状况/资源、HTTP 和 gRPC 的吞吐量/延迟、Actor、mTLS 等。
• Dapr Actor 仪表板 - 显示 Dapr sidecar 状态，包括 actor 调用吞吐量/延迟、计时器/提醒触发器和基于轮次的并发。

所以首先需要安装 Prometheus 和 Grafana，并且要配置 Prometheus 基于 Kubernetes 的自动发现（基于 Endpoints 和 Pods 都需要配置），将 Prometheus 配置为 Grafana 的数据源，我们这里已经部署了这两个应用：

$ kubectl get svc -n kube-mon
NAME          TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
grafana       NodePort   10.99.209.245    <none>        3000:30403/TCP   39d
prometheus    NodePort   10.100.236.253   <none>        9090:31561/TCP   81d
$ kubectl get pods -n kube-mon
NAME                           READY   STATUS    RESTARTS       AGE
grafana-d877667d6-4vgnd        1/1     Running   25 (60m ago)   39d
node-exporter-49l4f            1/1     Running   48 (60m ago)   81d
node-exporter-khqls            1/1     Running   46 (60m ago)   81d
node-exporter-wjwtb            1/1     Running   47 (60m ago)   81d
prometheus-649968556c-szb9c    1/1     Running   11 (60m ago)   14d

由于 Prometheus 配置了自动发现，所以正常默认情况下会自动抓取到 Dapr 应用的指标，可以在 Prometheus 的 Targets 列表中查找：

然后我们可以在 Grafana 中分别导入 https://github.com/dapr/dapr/tree/master/grafana 提供的 3 个 Dashboard。

不过直接导入后的 Dashboard 可能不会直接显示，需要做一些修改。

按照自己的系统配置后正常就可以看到仪表盘数据了。以下是显示 Dapr 系统服务指标的仪表板示例：

日志

日志可让你深入了解服务在运行时发生的情况，运行应用程序时，Dapr 将自动从 Dapr sidecar 和 Dapr 系统服务发出日志数据，但是，在应用程序代码中检测到的日志不会自动包含在内。若要从应用程序代码发出日志记录，可以导入特定的 SDK，例如 OpenTelemetry SDK。

Dapr 会发出结构化日志，每个日志条目采用以下格式：

在排查问题的时候，其中的 time 和 level 字段非常有用，time 字段将对日志条目进行排序，这样就可以准确查找特定的时间段。在进行故障排除时，debug 级别的日志条目会提供有关代码行为的详细信息。

此外默认情况下，Dapr 以纯文本格式发出结构化日志数据。每个日志条目都被格式化为包含键/值对的字符串，下面是纯文本格式的日志记录示例：

time="2020-03-11T17:08:48.303776-07:00" level=info msg="starting Dapr Runtime -- version 0.5.0-rc.3 -- commit v0.3.0-rc.0-155-g5dfcf2e" instance=dapr-pod-xxxx scope=dapr.runtime type=log ver=0.5.0-rc.3
time="2020-03-11T17:08:48.303913-07:00" level=info msg="log level set to: info" instance=dapr-pod-xxxx scope=dapr.runtime type=log ver=0.5.0-rc.3

虽然这种格式很简单，但很难解析，如果我们使用日志收集工具的话，使用 JSON 格式的日志则更容易解析。使用 JSON 条目时，日志工具可以索引和查询各个字段。 下面是 JSON 格式的相同日志条目：

{"instance":"dapr-pod-xxxx","level":"info","msg":"starting Dapr Runtime -- version 0.5.0-rc.3 -- commit v0.3.0-rc.0-155-g5dfcf2e","scope":"dapr.runtime","time":"2020-03-11T17:09:45.788005Z","type":"log","ver":"0.5.0-rc.3"}
{"instance":"dapr-pod-xxxx","level":"info","msg":"log level set to: info","scope":"dapr.runtime","time":"2020-03-11T17:09:45.788075Z","type":"log","ver":"0.5.0-rc.3"}

若要启用 JSON 格式，需要配置每个 Dapr sidecar，在自托管模式下，可以在命令行上指定标志 --log-as-json：

dapr run --app-id nodeapp --log-level info --log-as-json node app.js

在 Kubernetes 中，可以为应用程序的每个部署添加一个 dapr.io/log-as-json 注解，如下所示：

annotations:
  dapr.io/enabled: 'true'
  dapr.io/app-id: 'calculator-front-end'
  dapr.io/app-port: '80'
  dapr.io/config: 'dapr-config'
  dapr.io/log-as-json: 'true'

当使用 Helm 在 Kubernetes 群集中安装 Dapr 时，可以为所有 Dapr 系统服务启用 JSON 格式的日志记录：

helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
kubectl create namespace dapr-system
helm install dapr dapr/dapr --namespace dapr-system --set global.logAsJson=true

由 Dapr 发出的日志可以输入到监控后端，以供分析。日志收集器是一个组件，用于从系统收集日志并将其发送到监控后端，常用的日志收集器是 Fluentd，前面课程中我们已经介绍过如何在 Kubernetes 中设置 Fluentd、Elastic search 和 Kibana 来收集日志，也可以直接参考官方文档 https://docs.dapr.io/operations/monitoring/logging/fluentd/ 再次进行了解。

运行状况

服务的运行状态提供对其可用性的见解，每个 Dapr sidecar 都会暴露一个运行状况的 API，宿主环境可以使用该 API 来确定 sidecar 的运行状况。

GET http://localhost:3501/v1.0/healthz

该操作返回两个 HTTP 状态代码：

• 204：sidecar 运行正常时
• 500：sidecar 运行状况不正常

在自拓管模式下运行时，不会自动调用运行状况 API，不过，可以通过应用程序代码或运行状态监视工具调用 API。

在 Kubernetes 中运行时，Dapr sidecar-injector 会自动将 Kubernetes 配置为使用运行状况 API 来执行存活性探针和就绪探针。

Kubernetes 使用存活性探针来确定容器是否已启动并正在运行，如果存活性探针返回失败代码，Kubernetes 将假定容器状态为“死亡”并自动重启该容器，此功能可提高应用程序的整体可用性。

Kubernetes 使用就绪探针来确定容器是否已准备好开始接受流量，当某个 Pod 的所有容器都准备就绪时，就视为它已经准备就绪了，就绪情况决定 Kubernetes 服务是否可以在负载均衡场景中将流量路由到 Pod，未就绪的 Pod 将自动从负载均衡器中删除。

存活性探针和就绪探针具有多个可配置参数，两者都是在 Pod 清单文件的容器规范部分配置的。对于每个 sidecar 容器，Dapr 默认使用以下配置：

livenessProbe:
  httpGet:
    path: v1.0/healthz
    port: 3501
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: v1.0/healthz
    port: 3501
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

以下参数可用于探针：

• path 指定 Dapr 运行状况 API 端点
• port 指定 Dapr 运行状况 API 端口
• initialDelaySeconds 指定 Kubernetes 在首次开始探针容器之前需等待的秒数
• periodSeconds 指定 Kubernetes 在两次探针之间等待的秒数
• timeoutSeconds 指定 Kubernetes 在超时前等待 API 响应所需的秒数。超时将被解释为失败
• failureThreshold 指定在考虑容器处于不活动状态或未就绪之前，Kubernetes 将接受的失败状态代码的数量

对于在生产环境中运行分布式系统，详细的可观测性至关重要。Dapr 提供不同类型的遥测，包括分布式追踪、日志、指标和运行状况。

需要注意的是 Dapr 仅生成 Dapr 系统服务和 sidecar 的遥测数据，应用程序代码中的遥测不会自动包括在内。不过我们可以使用特定的 SDK 从应用程序代码中发出遥测数据。

Dapr 遥测是以基于开放标准的格式生成的，因此可以由大量可用的监视工具引入。 包括 Zipkin、Azure Application Insights、ELK Stack、New Relic 和 Grafana 等。此外 Dapr 还可以配置为发出结构化日志记录，建议使用 JSON 格式的结构化日志数据，因为后端监控工具可以对其进行索引，用户通过索引日志可在搜索日志记录时执行丰富的查询。同时 Dapr 也提供显示 Dapr 服务和配置相关信息的仪表板。