Dapr-可观测性

前言:

  前篇-Actor构建块 文章对Dapr的Actor构建块进行了解,本篇继续对可观测性 进行了解学习。

一、可观测性

 用于获取可观察性的系统信息称为遥测。 它可以分为四大类:

  1. 分布式跟踪 提供有关分布式业务事务中所涉及服务之间的流量的见解。
  2. 度量值 可让你深入了解服务的性能及其资源消耗情况。
  3. 日志记录 可提供代码的执行方式和错误发生的见解。
  4. 运行状况 终结点可让你深入了解服务的可用性。

 Dapr 可观察性构建基块将可观察性与应用程序分离。 它自动捕获由 Dapr 分支和 Dapr 系统服务生成的、构成 Dapr 控制平面的流量。 块将流量与跨多个服务的单个操作关联起来。 它还公开了系统的性能指标、资源使用情况和运行状况。 遥测以开放标准格式发布,使信息可以送入你选择的监视后端。 在这里,可以对信息进行可视化、查询和分析。

 由于 Dapr 抽象掉了该管道,因此应用程序不知道如何实现可观察性。 无需引用库或实现自定义检测代码。 Dapr 使开发人员能够专注于构建业务逻辑,而不是可观察性管道。 可观察性在 Dapr 系统级别配置,在服务之间保持一致,即使是由不同的团队创建,并使用不同的技术堆栈构建。

二、工作原理

 Dapr 的 Sidecar  启用内置可观察性功能。 服务通信时,Dapr 分支会截获流量并提取跟踪、指标和日志记录信息。 遥测以开放标准格式发布。 默认情况下,Dapr 支持 OpenTelemetry 和 Zipkin

 Dapr 提供可将遥测发布到不同后端监视工具的 收集 器。 这些工具提供了 Dapr 遥测用于分析和查询。 下图 显示了 Dapr 可观察性体系结构:

 

 步骤:

  1. 服务 A 调用服务 B 上的操作。调用将从服务 A 的 Dapr 挎斗路由到服务 B 的挎斗。
  2. 当服务 B 完成操作时,响应将通过 Dapr 分支发送回服务 A。 它们收集并发布每个请求和响应的所有可用遥测数据。
  3. 配置的收集器引入遥测数据,并将其发送到监视后端。

 三、特点

  • 分布式跟踪

  分布式跟踪提供了跨分布式应用程序中的服务的流量的见解。交换请求和响应消息的日志是用于解决问题的有用信息的来源。 硬部分正在关联属于同一业务事务的消息 。  

  Dapr 将 HTTP/GRPC Middleware 添加到 Dapr sidecar。 Middleware 拦截所有 Dapr 和应用程序流量,并自动注入关联ID以跟踪分布式事务。 此设计有如下优点:

    • 无需代码检测。 所有流量都会自动跟踪可配置的跟踪级别。
    • 跨微服务的一致跟踪行为。 跟踪是在 Dapr sidecar 上进行配置和管理的,因此它可以在服务之间保持一致,这些服务由不同的团队提供,并可能以不同的编程语言编写。
    • 可配置和可扩展。 通过利用 Zipkin API 和 OpenTelemetry 收集器,可以将 Dapr 追踪配置为与流行的追踪后端配合使用,包括客户可能有的自定义后端。
    • 可以同时定义和启用多个Exporter

  

   步骤:

  1. 服务 A 在服务 B 上调用操作。当服务 A 启动调用时,Dapr 将创建一个唯一的跟踪上下文并将其注入到请求中。
  2. 服务 B 接收请求,并对服务 C 调用操作。 Dapr 检测传入请求包含跟踪上下文,并通过将其注入到服务 C 的传出请求来传播。
  3. 服务 C 接收请求并对其进行处理。 Dapr 检测到传入请求包含跟踪上下文,并通过将其注入到服务 B 的传出响应来传播。
  4. 服务 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 终结点。
    • 指定 port Dapr 运行状况 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.ActivityParentId,让当前的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     

posted @ 2021-11-28 23:08  chaney1992  阅读(790)  评论(1编辑  收藏  举报