前言：
前篇-Actor构建块 文章对Dapr的Actor构建块进行了解，本篇继续对可观测性 进行了解学习。
一、可观测性
用于获取可观察性的系统信息称为遥测。 它可以分为四大类：
- 分布式跟踪 提供有关分布式业务事务中所涉及服务之间的流量的见解。
- 度量值 可让你深入了解服务的性能及其资源消耗情况。
- 日志记录 可提供代码的执行方式和错误发生的见解。
- 运行状况 终结点可让你深入了解服务的可用性。
Dapr 可观察性构建基块将可观察性与应用程序分离。 它自动捕获由 Dapr 分支和 Dapr 系统服务生成的、构成 Dapr 控制平面的流量。 块将流量与跨多个服务的单个操作关联起来。 它还公开了系统的性能指标、资源使用情况和运行状况。 遥测以开放标准格式发布，使信息可以送入你选择的监视后端。 在这里，可以对信息进行可视化、查询和分析。
由于 Dapr 抽象掉了该管道，因此应用程序不知道如何实现可观察性。 无需引用库或实现自定义检测代码。 Dapr 使开发人员能够专注于构建业务逻辑，而不是可观察性管道。 可观察性在 Dapr 系统级别配置，在服务之间保持一致，即使是由不同的团队创建，并使用不同的技术堆栈构建。
二、工作原理
Dapr 的 Sidecar 启用内置可观察性功能。 服务通信时，Dapr 分支会截获流量并提取跟踪、指标和日志记录信息。 遥测以开放标准格式发布。 默认情况下，Dapr 支持 OpenTelemetry 和 Zipkin。
Dapr 提供可将遥测发布到不同后端监视工具的 收集 器。 这些工具提供了 Dapr 遥测用于分析和查询。 下图 显示了 Dapr 可观察性体系结构：
步骤：
- 服务 A 调用服务 B 上的操作。调用将从服务 A 的 Dapr 挎斗路由到服务 B 的挎斗。
- 当服务 B 完成操作时，响应将通过 Dapr 分支发送回服务 A。 它们收集并发布每个请求和响应的所有可用遥测数据。
- 配置的收集器引入遥测数据，并将其发送到监视后端。
三、特点
-
分布式跟踪
分布式跟踪提供了跨分布式应用程序中的服务的流量的见解。交换请求和响应消息的日志是用于解决问题的有用信息的来源。 硬部分正在关联属于同一业务事务的消息 。
Dapr 将 HTTP/GRPC Middleware 添加到 Dapr sidecar。 Middleware 拦截所有 Dapr 和应用程序流量，并自动注入关联ID以跟踪分布式事务。 此设计有如下优点：
-
- 无需代码检测。 所有流量都会自动跟踪可配置的跟踪级别。
- 跨微服务的一致跟踪行为。 跟踪是在 Dapr sidecar 上进行配置和管理的，因此它可以在服务之间保持一致，这些服务由不同的团队提供，并可能以不同的编程语言编写。
- 可配置和可扩展。 通过利用 Zipkin API 和 OpenTelemetry 收集器，可以将 Dapr 追踪配置为与流行的追踪后端配合使用，包括客户可能有的自定义后端。
- 可以同时定义和启用多个Exporter
步骤：
- 服务 A 在服务 B 上调用操作。当服务 A 启动调用时，Dapr 将创建一个唯一的跟踪上下文并将其注入到请求中。
- 服务 B 接收请求，并对服务 C 调用操作。 Dapr 检测传入请求包含跟踪上下文，并通过将其注入到服务 C 的传出请求来传播。
- 服务 C 接收请求并对其进行处理。 Dapr 检测到传入请求包含跟踪上下文，并通过将其注入到服务 B 的传出响应来传播。
- 服务 B 接收响应并对其进行处理。 然后，它会创建新的响应，并通过将跟踪上下文注入到服务 A 的传出响应来传播跟踪上下文。
Zipkin 是开源分布式跟踪系统。 它可以摄取和可视化遥测数据。 Dapr 提供对 Zipkin 的默认支持。以下为默认支持的dapr设置
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: daprConfig
spec:
tracing:
##采样率
samplingRate: "1"
zipkin:
##zipkin地址
endpointAddress: http://localhost:9411/api/v2/spans
-
指标
指标（Metrics）是在一段时间内收集和存储的一系列度量值和计数。 Dapr 指标 提供监控功能，以了解 Dapr sidecar 和系统服务的行为。 例如，Dapr sidecar 和用户应用之间的服务指标可以展示调用延迟、流量故障、请求的错误率等。 Dapr 的系统服务度量 则可以显示 sidecar 注入失败，系统服务的运行状况 ( 包括 CPU 使用率，actor 位置数量等)
每个Sidecar和系统服务都公开一个在端口9090上侦听的指标终结点。 Prometheus 指标 Scrapper 从每个终结点捕获指标，并将信息发布到监视后端。
Dapr 为 Dapr 系统服务及其运行时生成一组大量指标。 示例包括：
| 指标 | 源 | 说明 |
|---|---|---|
| dapr_operator_service_created_total | 系统 | Dapr Operator service 创建的 Dapr 服务总数。 |
| dapr_injector_sidecar_injection/requests_total | 系统 | Dapr Sidecar-Injector 服务收到的挎斗注入请求总数。 |
| dapr_placement_runtimes_total | 系统 | 向 Dapr 放置服务报告的主机总数。 |
| dapr_sentry_cert_sign_request_received_total | 系统 | Dapr Sentry 服务) (收到的证书签名请求数。 |
| dapr_runtime_component_loaded | 运行时 | 已成功加载的 Dapr 组件数。 |
| dapr_grpc_io_server_completed_rpcs | 运行时 | 按方法和状态的 gRPC 调用的计数。 |
| dapr_http_server_request_count | 运行时 | HTTP 服务器中启动的 HTTP 请求数。 |
| dapr_http/client/sent_bytes | 运行时 | 请求正文中发送的总 (不包括 HTTP 客户端) 标头。 |
配置指标：
运行时，可以通过在 Dapr 命令中包含 参数来 --enable-metrics=false 禁用指标收集终结点。 或者，还可使用 参数更改终结点的默认 --metrics-port 9090 端口。
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: dapr-config
namespace: dapr-trafficcontrol
spec:
tracing:
samplingRate: "1"
metric:
enabled: false
Prometheus 抓取器将指标收集并发布到监视后端后，如何理解原始数据？ 用于分析指标的常用可视化工具是 Grafana。 使用 Grafana，可以从可用指标创建仪表板。
-
日志记录
Dapr 生成 日志，以提供 sidecar 操作的可见性，并帮助用户识别问题并执行调试。 日志事件包含由 Dapr 系统服务生成的警告，错误，信息和调试消息。
Dapr以纯文本形式或JSON格式生成结构化日志到标准输出。 默认情况下，所有 Dapr 进程 (运行时和系统服务) 都以纯文本写入控制台输出。 要启用 JSON 格式的日志，您需要在运行 Dapr 进程时添加 --log-as-json 命令标志。
Dapr 基于以下结构生成日志：
| 字段 | 说明 | 示例 |
|---|---|---|
| time | ISO8601 时间戳 | 2011-10-05T14:48:00.000Z |
| level | 日志级别 (info/warn/debug/error) | info |
| type | 日志类型 | log |
| msg | 日志消息 | hello dapr! |
| scope | 日志记录范围 | dapr.runtime |
| instance | Dapr 运行位置的主机名 | dapr-pod-xxxxx |
| app_id | Dapr 应用 ID | dapr-app |
| ver | Dapr 运行时版本 | 1.0 |
-
运行情况
Dapr 提供了一种使用 HTTP /healthz 端点来确定其健康状况的方法。 通过此端点，对Dapr 进程或 sidecar进行探测，可以确定其运行状况，从而确定其就绪程度和活跃度。
GET http://localhost:3500/v1.0/healthz
在自承载模式下运行时，不会自动调用运行状况 API。 不过，可以从应用程序代码或运行状况监视工具调用 API。
在 Kubernetes 中运行时，Dapr sidecar-execut 会自动将 Kubernetes 配置为使用运行状况 API 执行运行情况 探测 和 就绪情况探测。
Kubernetes 使用运行状态探测来确定容器是否已启动并正在运行。 如果运行情况探测返回失败代码，Kubernetes 将假定容器已死并自动重启。 此功能可提高应用程序的整体可用性。
Kubernetes 使用就绪情况探测来确定容器是否已准备好开始接受流量。 当 Pod 的所有容器都准备就绪时，它被视为已就绪。 就绪情况确定 Kubernetes 服务是否可以在负载均衡方案中将流量引导到 Pod。 未就绪的 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
以下参数可用于探测：
-
path指定 Dapr 运行状况 API 终结点。- 指定
portDapr 运行状况 API 端口。 - 指定 Kubernetes 在开始首次探测容器之前等待
initialDelaySeconds的秒数。 periodSeconds指定 Kubernetes 在每个探测之间等待的秒数。- 指定 Kubernetes 在超时之前等待来自 API 的响应
timeoutSeconds的秒数。超时被解释为失败。 - 指定 Kubernetes 在考虑容器未处于活动状态或未就绪之前将接受的失败
failureThreshold状态代码数。
四、.Net Core 应用
1、添加以下Nuget包：
注：版本很重要，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
2、修改Startup文件：添加监控
public class Startup { public Startup(IConfiguration configuration) { Configuration = configuration; } public IConfiguration Configuration { get; } // This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices(IServiceCollection services) { services.AddControllers(); services.AddActors(option => { option.Actors.RegisterActor<OrderStatusActor>(); }); //添加TelemetryTracing监控 services.AddOpenTelemetryTracing((tracerProviderBuilder) => tracerProviderBuilder .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("DaprBackEnd")) .AddAspNetCoreInstrumentation() .AddHttpClientInstrumentation()
//设置zipkin相关设置 .AddZipkinExporter(zipkinOptions => { zipkinOptions.Endpoint = new Uri("http://localhost:9411/api/v2/spans"); } )); } // This method gets called by the runtime. Use this method to configure the HTTP request pipeline. public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { //开启.Net的OpenTelemetry，然后修改Diagnostics.Activity的ParentId，让当前的Tracing跟Dapr Sidecar传来的TraceId一致 endpoints.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}"); }); endpoints.MapControllers(); endpoints.MapActorsHandlers(); }); } }
3、启动dapr应用：
dapr run --dapr-http-port 3511 --app-port 8220 --app-id DaprBackEnd dotnet .\DaprBackEnd.dl
4、使用Dapr CLI命令：
dapr invoke --app-id DaprBackEnd --method /Amazing
5、查看检测效果：
打开Zipkin，地址：http://localhost:9411/, 来看一下Zipkin的Tracing
总结：
详细的可观察性在生产中运行分布式系统至关重要。
Dapr 提供不同类型的遥测，包括分布式跟踪、日志记录、指标和运行状况状态。
Dapr 仅生成 Dapr 系统服务和分支的遥测。 不会自动包含应用程序代码中的遥测数据。 不过，可以使用特定的 SDK （如 OpenTelemetry SDK for .NET）从应用程序代码发出遥测数据。
Dapr 遥测采用基于开放标准的格式生成，因此可通过大量可用的监视工具来引入。 示例包括 Zipkin、Azure 应用程序 Insights、ELK Stack、New Relic 和 Grafana。 有关如何监视具有特定监视后端的 Dapr 应用程序的教程，请参阅 Dapr 文档中的 监视应用程序 Dapr 。
参考：
https://docs.microsoft.com/zh-cn/dotnet/architecture/dapr-for-net-developers/observability