关于c#:手把手教你学Dapr-9-可观测性

目录

手把手教你学 Dapr – 1. .Net 开发者的大时代

手把手教你学 Dapr – 2. 必须晓得的概念

手把手教你学 Dapr – 3. 应用 Dapr 运行第一个.Net 程序

手把手教你学 Dapr – 4. 服务调用

手把手教你学 Dapr – 5. 状态治理

手把手教你学 Dapr – 6. 公布订阅

手把手教你学 Dapr – 7. Actors

手把手教你学 Dapr – 8. 绑定

手把手教你学 Dapr – 9. 可观测性

介绍

通过 Tracing(跟踪)、Metrics(指标)、Logs(日志)和 Health(运行状况)监控应用程序。

分布式跟踪

Dapr 应用 Zipkin 协定进行分布式跟踪 和 Metrics 收集。因为 Zipkin 协定的普遍性，许多后端都是开箱即用的，例如 Stackdriver、Zipkin、New Relic 等。联合 OpenTelemetry Collector，Dapr 能够将跟踪导出到许多其余后端，包含但不限于 Azure Monitor、Datadog、Instana、Jaeger 和 SignalFX。

Tracing 设计

Dapr 在 Dapr Sidecar 中增加了一个 HTTP/gRPC 中间件。中间件拦挡所有 Dapr 和应用程序流量，并主动注入关联 ID 以跟踪分布式事务。这种设计有几个益处：

• 无需代码检测。应用可配置的跟踪级别主动跟踪所有流量。
• 跨微服务的一致性跟踪行为。跟踪是在 Dapr Sidecar 上配置和治理的，因而它在由不同团队制作并可能用不同编程语言编写的服务之间保持一致。
• 可配置和可扩大。利用 Zipkin API 和 OpenTelemetry Collector，Dapr 跟踪能够配置为与风行的跟踪后端一起应用，包含客户可能领有的自定义后端。
• 您能够同时定义和启用多个导出器。

<!– more –>

W3C 关联 ID

Dapr 应用规范的 W3C 跟踪上下文标头。对于 HTTP 申请，Dapr 应用 traceparent 标头。对于 gRPC 申请，Dapr 应用 grpc-trace-bin 标头。当一个没有跟踪 ID 的申请达到时，Dapr 会创立一个新的。否则，它会沿着调用链传递跟踪 ID。

配置

Dapr 应用概率抽样。采样率定义了对跟踪跨度进行采样的概率，其值能够介于 0 和 1（含）之间。默认采样率为 0.0001（即采样 10,000 个跨度中的 1 个）。

要更改默认跟踪行为，请应用配置文件。例如，以下配置对象将采样率更改为 1（即每个跨度都被采样），并应用 Zipkin 协定将跟踪发送到位于 http://zipkin.default.svc.clu… 的 Zipkin 服务器

yaml 文件门路：%UserProfile%\.dapr\config.yaml

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: tracing
  namespace: default
spec:
  tracing:
    samplingRate: "1"
    zipkin:
      endpointAddress: "http://zipkin.default.svc.cluster.local:9411/api/v2/spans"

注 ：将采样率更改为 0 会齐全 禁用 跟踪。

W3C 跟踪上下文

Dapr 应用 W3C 跟踪上下文对服务调用和公布 / 订阅音讯进行分布式跟踪。Dapr 实现了生成和流传跟踪上下文信息的所有沉重工作，仅在极少数状况下，您须要流传或创立跟踪上下文。

W3C trace context 有以下劣势：

• 为单个跟踪和申请提供惟一标识符，容许将多个提供程序的跟踪数据链接在一起。
• 提供转发特定于供应商的跟踪数据的约定机制，并防止跟踪在多个工具参加单个事务时中断。
• 提供中间商、平台和硬件提供商能够反对的行业标准。

有两种状况须要理解如何应用跟踪：

1. Dapr 在服务之间生成并流传跟踪上下文。
2. Dapr 生成跟踪上下文，您须要将跟踪上下文流传到另一个服务，或者您生成跟踪上下文，Dapr 将跟踪上下文流传到服务。

Dapr 在服务之间生成并流传跟踪上下文

在某些状况下，Dapr 会为您实现所有工作。您不须要创立和流传任何跟踪标头。Dapr 负责创立所有跟踪标头并流传它们。让咱们通过示例来理解场景；

1. 单个服务调用（服务 A -> 服务 B）

   Dapr 在服务 A 中生成跟踪标头，这些跟踪标头从服务 A 流传到服务 B。

2. 多个程序服务调用（服务 A -> 服务 B -> 服务 C）

   Dapr 在服务 A 中的申请开始时生成跟踪标头，这些跟踪标头从服务 A-> 服务 B -> 服务 C 等流传到进一步启用 Dapr 的服务。

3. 申请是来自内部 endpoint（例如从网关服务到启用 Dapr 的服务 A）

Dapr Sidecar 健康检查

Dapr 提供了一种应用 HTTP /healthz endpoint 来确定其健康状况的办法。有了这个 endpoint，能够探测 Dapr 过程或边车的健康状况，从而确定其筹备状况和活跃度。

在将 Dapr 部署到托管平台（例如 Kubernetes）时，会主动为您配置 Dapr health endpoint。您无需进行任何配置。

Health endpoint: 与 Kubernetes 集成

Kubernetes 应用 readiness 和 liveness 探测来确定容器的健康状况。

kubelet 应用流动探针来晓得何时重新启动容器。例如，流动探测能够捕捉死锁，即应用程序正在运行，但无奈获得停顿。在这种状态下重新启动容器有助于使应用程序更可用，只管存在缺点。

kubelet 应用就绪探针来理解容器何时筹备好开始承受流量。当 pod 的所有容器都准备就绪时，它就被认为是筹备好了的。这种筹备信号的一个用处是管制哪些 Pods 被用作 Kubernetes 服务的后端。当 Pod 未筹备好时，它将从 Kubernetes 服务负载均衡器中删除。

当与 Kubernetes 集成时，Dapr Sidecar 被注入了一个 Kubernetes 探针配置，通知它应用 Dapr healthz endpoint。这是由 Sidecar Injector 零碎服务实现的。与 kubelet 的集成如下图所示。

如何在 Kubernetes 中配置活性探针

在 pod 配置文件中，在容器标准局部增加了 liveness 探针，如下所示：

livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 3
     periodSeconds: 3

在下面的例子中，periodSeconds 字段指定 kubelet 应该每 3 秒执行一次活性探测。initialDelaySeconds 字段通知 kubelet 在执行第一次探测之前应该期待 3 秒。

注：任何大于或等于 200 且小于 400 的代码都示意胜利。其余代码示意失败。

如何在 Kubernetes 中配置就绪探针

就绪探针的配置相似于活性探针。惟一的区别是您应用 readinessProbe 字段而不是 livenessProbe 字段。

readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

如何应用 Kubernetes 配置 Dapr Sidecar health endpoint

此配置由 Sidecar Injector 服务主动实现。Dapr 在端口 3500 上有它的 HTTP health endpint /v1.0/healthz，这能够与 Kubernetes 一起应用以进行就绪和活跃度探测。当注入 Dapr sidecar 时，readiness 和 liveness 探针在 pod 配置文件中配置为以下值。

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

.Net 中应用可观测性

创立 Assignment.Server

创立 类库 我的项目，并增加 Dapr.AspNetCore, OpenTelemetry, OpenTelemetry.Instrumentation.AspNetCore, OpenTelemetry.Instrumentation.Http,OpenTelemetry.Extensions.Hosting 和OpenTelemetry.Exporter.ZipkinNuGet 包援用，最初批改程序端口为 5000。

!!! 注：版本很重要，NuGet 要关上 蕴含预发行版，并且应用指定版本

OpenTelemetry-1.2.0-beta1

OpenTelemetry.Instrumentation.AspNetCore-1.0.0-rc8

OpenTelemetry.Instrumentation.Http-1.0.0-rc8

OpenTelemetry.Exporter.Zipkin-1.2.0-beta1

OpenTelemetry.Extensions.Hosting-1.0.0-rc8

批改 program.cs

using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOpenTelemetryTracing((tracerProviderBuilder) =>
    tracerProviderBuilder
        .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("testobservability"))
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddZipkinExporter(zipkinOptions =>
        {zipkinOptions.Endpoint = new Uri("http://localhost:9411/api/v2/spans");
        }
    )
);
var app = builder.Build();

app.Map("/Amazing", async (HttpContext context) =>
{if (context.Request.Headers.TryGetValue("traceparent", out var traceparent))
    {Console.WriteLine($"TraceParent: {traceparent}");
    }
    if (context.Request.Headers.TryGetValue("tracestate", out var tracestate))
    {Console.WriteLine($"TraceState: {tracestate}");
    }

    System.Diagnostics.Activity.Current?.SetParentId(traceparent.ToString());
    _ = await new HttpClient().GetStringAsync("https://www.baidu.com");
    Console.WriteLine($"Invoke succeed: traceID:{traceparent}");
});

app.Run();

能够看到咱们间接演示了一个好玩的用法，就是开启.Net 的 OpenTelemetry，而后批改Diagnostics.Activity 的ParentId，让以后的 Tracing 跟 Dapr Sidecar 传来的 TraceId 统一。

运行 Assignment.Server

应用 Dapr CLI 来启动，先应用命令行工具跳转到目录 dapr-study-room\Assignment07\Assignment.Server，而后执行上面命令

dapr run --app-id testobservability --app-port 5000 --dapr-http-port 3500 --dapr-grpc-port 50001 dotnet run

应用 Dapr CLI 发个命令看看

dapr invoke --app-id testobservability --method /Amazing

关上 Zipkin，地址：http://localhost:9411/, 来看一下 Zipkin 的 Tracing，不单有 Dapr Sidecar 的申请记录进来了，还跟 HttpClient 的捆绑在了起来，是的，乏味的就在这里。

除了能够跟踪 HttpClient 以外，还有 EF Core 等都集成了。

至于 Metrics 和 Logs 集成也是非常简单，须要搭配不同的后端如 Prometheus, Fluentd 等。甚至能够通过自定义 Exporter 自行对接一些云厂商的云服务。

本章源码

Assignment09

https://github.com/doddgu/dap…

咱们正在口头，新的框架、新的生态

咱们的指标是 自在的 、 易用的 、 可塑性强的 、 功能丰富的 、 强壮的。

所以咱们借鉴 Building blocks 的设计理念，正在做一个新的框架MASA Framework，它有哪些特点呢？

• 原生反对 Dapr，且容许将 Dapr 替换成传统通信形式
• 架构不限，单体利用、SOA、微服务都反对
• 反对.Net 原生框架，升高学习累赘，除特定畛域必须引入的概念，保持不造新轮子
• 丰盛的生态反对，除了框架以外还有组件库、权限核心、配置核心、故障排查核心、报警核心等一系列产品
• 外围代码库的单元测试覆盖率 90%+
• 开源、收费、社区驱动
• 还有什么？咱们在等你，一起来探讨

通过几个月的生产我的项目实际，已实现 POC，目前正在把之前的积攒重构到新的开源我的项目中

目前源码已开始同步到 Github（文档站点在布局中，会缓缓欠缺起来）：

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

QQ 群：7424099

微信群：加技术经营微信（MasaStackTechOps），备注来意，邀请进群