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

今日已办

OpenTelemetry Logs

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

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

Overview

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

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 等接收通知。

明日待办

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