腾讯mini项目-【指标监控服务重构】2023-07-19

今日已办

OpenTelemetry Logs

通过日志记录 API 支持日志收集

集成现有的日志记录库和日志收集工具

Overview

  • 日志记录 API - Logging API,允许您检测应用程序并生成结构化日志
  • 旨在与其他 telemerty data(例如metric和trace)配合使用,以提供统一的可观测性解决方案
  • 结构化日志记录,允许attributesmetadata附加上下文信息到日志条目。包含相关详细信息,例如时间戳、请求 ID、用户 ID、相关 ID 以及其他有助于日志分析和故障排除的自定义上下文

腾讯mini项目-【指标监控服务重构】2023-07-19_第1张图片

Different types of logs

OpenTelemetry 支持从应用程序系统内的各种来源捕获日志。根据日志的生成和收集方式,日志可以分为 3 类。

System and infrastructure logs

  • System logs 提供有关系统操作性能安全性的宝贵信息。

  • 通常由系统内的各个组件生成,包括操作系统、应用程序、网络设备和服务器。

  • 是在主机级别写入的,具有预定义的格式和内容,无法轻易更改。

  • 不包含有关 Trace 上下文的信息。

Legacy first-party logs

  • First-party logs由内部应用程序生成,记录特定的应用程序事件、错误和用户活动,助于应用程序调试和故障排除。

  • 更改日志的写入方式以及包含的信息。例如,要将日志与Trace关联起来,手动将 Trace Context 添加到每个日志语句中,或者使用日志库的插件自动执行此操作。 例如,要传播上下文并将日志记录与Trace关联,可以在日志消息中使用以下属性

    • trace_id for TraceId, hex-encoded.

    • span_id for SpanId, hex-encoded.

    • trace_flags for trace flags, formatted according to W3C traceflags format.

For example:

request failed trace_id=958180131ddde684c1dbda1aeacf51d3 span_id=0cf859e4f7510204

New first-party logs

  • 附加上下文信息到日志条目,例如标签、属性或元数据。
  • 记录不同级别的事件或消息,例如调试、信息、警告、错误等。
  • 标准化跨分布式系统传播日志中的上下文。

OpenTelemetry Collector

  • 灵活且可扩展的代理,收集、处理和导出 telemetry data,简化从多个来源接收和管理 telemetry data ,导出到多个后端或可观测系统。
  • 支持多种日志源,包括应用程序日志、日志文件、日志库和第三方日志系统。集成流行的日志框架和库,从而实现日志数据的无缝摄取。
  • 提供转换和丰富日志数据的能力。可以修改日志属性、添加元数据或使用其他上下文信息丰富日志,以增强分析和故障排除的价值。
  • 收集和处理后,将日志数据导出到各种日志记录后端或系统。支持将日志导出到流行的日志平台、存储系统或日志管理 用于长期存储、分析和可视化的工具

OpenTelemetry Backend

将日志数据导出到日志后端后,可以使用平台的功能处理和分析日志。包括过滤、搜索、聚合和可视化日志,以深入了解应用程序的行为并解决问题。

Sampling and rate-limiting

采样 Sampling 通过减少创建(sampled)Span 的数量来降低 Trace 的成本和冗长性。在性能方面,采样可以节省收集、处理和导出 Span 所需的 CPU 周期和内存

Sampling: when and where

采样可能发生在处理 Span 的不同阶段:

  • When a trace is created - head-based sampling;
  • When a trace is received by a backend - rate-limiting sampling;
  • When a complete trace is available - tail-based sampling.

Sampling probability

采样提供了采样概率,可以仅使用采样范围的一部分对所有范围进行准确的统计计数。例如,如果采样概率为 50%,采样的 Span 数为 10,则调整后的(总) Span 数为 10 / 50% = 20 ; 以局部计算的概率来推算、估计整体

Name Side Adjusted count Accuracy
Head-based sampling Client-side Yes 100%
Rate-limiting sampling Server-side Yes <90%
Tail-based sampling Server-side Yes <90%

Head-based sampling

  • 尽早做出采样决策,并使用上下文将其传播给其他参与者。这样可以通过不收集已删除Span(操作)的任何 telemetry data节省 CPU 和内存资源
  • 最简单、最准确、最可靠的采样方法。
  • 缺点是无法对有错误的 Span 进行采样,因为创建 Span 时该信息不可用。为了解决这个问题,可以使用基于尾部的采样 - tail-based sampling。
  • 不考虑流量峰值,并且可能收集比预期更多的数据。这就是速率限制 rate-limiting 采样变得方便的地方

OpenTelemetry head-based sampling

OpenTelemetry 有 2 个 Span 属性负责客户端采样

  • IsRecording - when false, span discards 丢弃 attributes, events, links etc.
  • Sampled - when false, OpenTelemetry drops 删除the span.

防止收集昂贵的数据

if span.IsRecording() {
    // collect expensive data
}

Sampler 是一个接受即将创建的根 Span 的函数。该函数返回一个采样决策:

  • Drop - trace is dropped. IsRecording = false, Sampled = false.
  • RecordOnly - trace is recorded but not sampled. IsRecording = true, Sampled = false.
  • RecordAndSample - trace is recorded and sampled. IsRecording = true, Sampled = true.

默认情况下,OpenTelemetry 对所有 Trace 进行采样,可以修改配置为对部分 Trace 进行采样。在这种情况下,后端使用采样概率 sampling probability 来调整 Span 的数量

OpenTelemetry samplers

  • AlwaysOn每个 Trace 进行采样,例如,将为每个请求启动并导出新的 Trace。
  • AlwaysOff 采样器不采样任何 Traces,或者换句话说,丢弃所有 Traces。可以用于执行负载测试或暂时禁用 Tracing。
  • TraceIDRatioBased 采样器使用Trace ID一小部分 Traces 进行采样,例如 20% 的Tracing 。
  • Parent-based 是一个复合采样器,其行为根据 Span 的父级而有所不同。当开始新的 Trace 时,采样器会决定是否对其进行采样并将该决定传播到其他服务

Rate-limiting sampling

  • 发生在服务器端,并确保不会超出某些限制,例如,它允许每秒采样 10 条或更少的Traces。
  • 支持调整计数 adjusted counts ,但精度较低。为了获得更好的结果并提高性能,应该将限速采样与基于头的采样- head-based sampling 结合使用,后者更加高效和准确。
  • 大多数后端(包括 Uptrace)会在必要时自动应用速率限制采样

Tail-based sampling

  • head-based sampling 采样决策是预先做出的,并且通常是随机的。无法对失败或异常长的操作进行采样,因为该信息仅在 Trace 结束时可用
  • tail-based sampling ,延迟采样决策,直到 Trace 的所有 Span 都可用,可以根据 Trace 中的所有数据做出更好的采样决策。例如,可以对失败或异常长的 Trace 进行采样
  • 大多数后端(包括 Uptrace)必要时自动应用,可以 OpenTelemetry Collector with tailsamplingprocessoropen in new window根据需要配置采样。

Uptrace

  • 一个 OpenTelemetry 后端,具有直观的查询生成器、丰富的仪表板、警报规则以及大多数语言和框架的集成。可以在单个服务器上处理数十亿个 Span 和 Metric ,并允许以低 10 倍的成本监控应用程序。
  • 使用 ClickHouse 数据库来存储 Trace 、Metric 和 Log 。监控应用程序并设置自动警报以通过电子邮件、Slack、Telegram 等接收通知。

明日待办

  1. 组会汇总进度和问题
  2. 继续学习文档

你可能感兴趣的:(重构,服务器,go)