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

今日已办

根据导师的指导意见

1. 修改了otelclient相关配置的代码

2. 认真学习uptrace的文档，会比otel、signoz的好理解：

   什么是OpenTelemetry

   • https://uptrace.dev/opentelemetry/architecture.html#opentelemetry-sdk

     trace部分介绍

   • https://uptrace.dev/opentelemetry/distributed-tracing.html

     trace的otel SDK api，是通用的

   • https://uptrace.dev/opentelemetry/go-tracing.html

     metrics部分介绍

   • https://uptrace.dev/opentelemetry/metrics.html

     metrics的otel SDK api，是通用的

   • https://uptrace.dev/opentelemetry/go-metrics.html

     logs部分介绍

   • https://uptrace.dev/opentelemetry/logs.html

     collector介绍

   • https://uptrace.dev/opentelemetry/collector.html

OpenTelemetry

Start

What is OpenTelemetry?

• 开源可观测框架

• 为所有类型的可观测信号（如trace、metric、log）提供统一标准

• 指定如何收集，提供通用数据格式和API，共享和重用数据，集成各种可观测工具和平台

• 灵活性、互操作性和可扩展性

Telemetry data types

• Trace追踪，跨多个组件和服务的请求或操作的执行路径。提供详细的计时和上下文信息（trace IDs, span IDs, and other metadata）
• Metric指标，系统行为或资源利用率的定量度量。监视和分析一段时间的性能，可用与警报、容量规划和趋势分析，例如CPU使用率、内存消耗或请求延迟；允许自定义和记录指标
• Log，事件、错误和活动的结构化或非结构化文本信息，助于调试、审核和故障排除

Architecture

Glossary

• OpenTelemetry API ：收集数据
• OpenTelemetry SDK ： 官方接口实现，有各种编程语言的实现；检测应用程序并收集数据，导出数据到后端，
• OpenTelemetry Collector ：应用程序与后端之间的代理。灵活、可扩展的方式来接收数据，处理，导出数据到存储后端，集成不同后端和系统
• OTLP ：SDK与收集器用于数据导出到后端或其他收集器的协议，指定数据编码格式。（OTLP/grpc）或（OLTP/HTTP）
• OpenTelemetry backend ：接收、存储、分析数据。聚合、查询、可视化
• OpenTelemetry Jaeger ：存储、分析、可视化数据的默认OTEL后端
• Rescoure ：提供受监视实体（服务、进程、容器）的元数据，标识、筛选、分组

---

Distributed tracing

Introduce

• 查看一个跨不同服务、系统的请求过程每个操作的时机，日志和错误
• 提供系统行为的可见性，帮助识别性能问题，协助调试，并帮助确保分布式应用程序的可靠性和可扩展性
• 跟踪微服务架构上下文

Spans

一个trace的一个操作（工作单元）。可以是RPC、db query、内部函数调用

A span name (operation name). 【名称】

• A parent span. 【父span】

• A span kind. 【类型】

• Start and end time. 【开始、结束时间】

• A status that reports whether operation succeeded or failed. 【上报操作的状态】

• A set of key-value attributes describing the operation. 【属性】

• A timeline of events. 【事件时间线】

• A list of links to other spans. 【与其他span的link】

• A span context that propagates trace ID and other data between different services. 【在不同服务之间传播traceID 和 其他数据的跨度上下文】

trace 是个 span 树

Span names

后端工具名称和相似的属性分组

以下名称很好，因为它们简短、独特，并且有助于将相似的跨度组合在一起：

跨度名称	评论
GET /projects/:id	好。带有参数名称的路由名称。
select_project	好。不带参数的函数名称。
SELECT * FROM projects WHERE id = ?	好。带有占位符的数据库查询。

Span kind

跨度类型必须具有以下值之一：

• server操作，例如 HTTP 服务器处理程序。
• 客户端操作的client，例如 HTTP 客户端请求。
• 消息生产者的生产者，例如，Kafka producer。
• 消费者一般用于消息consumer和异步处理，例如 Kafka 消费者。
• internal用于内部操作。

Satus Code

状态代码指示操作是成功还是失败。它必须具有以下值之一：

• ok - 成功。
• error - 失败。
• unset - 允许后端分配状态的默认值。

Attributes

记录上下文信息，描述跨度。如HTTP endpoint 可能具有http.method = GET /http.route = /projects/:id 等属性

Events

具有开始时间和任意数量的属性的事件来注释跨度。事件和跨度之间的主要区别在于事件没有结束时间（因此没有持续时间）

事件通常表示异常、错误、日志和消息（例如在 RPC 中），支持自定义事件

Context

Span Context 在 Span 通过不同的组件和服务传播时携带有关该 Span 的信息。

Trace/Span Context 是请求范围的数据，例如：

• Trace ID。表示整个Trace的全局唯一标识符。Trace中的所有Span都具有相同的 TraceID。
• Span ID。Trace中特定范围的唯一标识符。Trace中的每个Span都有不同的 SpanID。
• Trace flags。指示Trace的各种属性（如是否对其进行采样）的标志。采样是指确定应记录哪些Span并将其报告给可观测性后端的过程。
• Trace State。一个可选字段，其中包含与Trace相关的其他供应商或应用程序特定的数据。

Span Context 对于维护分布式系统中Span的连续性和相关性非常重要。它允许不同的服务和组件将其Span与正确的Trace相关联，并提供对请求或事务流的端到端可见性。

Span Context 通常使用服务之间通信协议的标头或元数据进行传播，类似于baggage 数据的传播方式。这可确保当服务收到请求时，它可以提取Span Context并将传入 Span 与正确的 Trace 相关联。

使用上下文中的数据进行 Span 关联或采样，例如使用 Trace ID 来了解哪些Span属于哪些 Trace

Context propagation

上下文传播可确保相关的上下文数据（ trace IDs, span IDs, and other metadata ）在应用程序的不同服务和组件之间一致地传播。

• 进程内传播

  • 显式传播，将Context以函数参数传递
  • 隐式传播，将Context存储到线程局部变量

• 分布式传播

  • W3C Trace Context in traceparent header ,traceparent=00-84b54e9330faae5350f0dd8673c98146-279fa73bc935cc05-01
  • B3 Zipkin start with x-b3-, for example, X-B3-TraceId

Baggage

工作原理与Span Context 类似，自定义键值对属性在服务间传播，类似grpc的metadata

属性可以与请求或事物处理相关的上下文信息，userId、sessionId、metadata

跨分布式系统维护和关联上下文信息，提供了一阵个系统中传递相关数据的标准话方法

Instrumentations

OpenTelemetry instrumentations 是流行框架和库的插件，它们使用 OpenTelemetry API 来记录重要操作，例如 HTTP 请求、数据库查询、日志、错误等

What to instrument?

无需检测每个操作即可充分利用跟踪。考虑一下操作的优先级：

• 网络操作，例如 HTTP 请求或 RPC 调用。
• 文件系统操作，例如，读取/写入文件。
• 结合网络和文件系统操作的数据库查询。
• 错误和日志 ，例如，使用结构化日志记录

---

Timeseries metrics

Introduce

如何收集，聚合，发送 metrics 到 Otel APM 工具的标准

与现有的 metrics instrumentation protocols 配合使用

What are metrics?

标识系统运行情况和性能的数字化数据， 如 CPU utilization, network traffic, and database connections.

使用metrics 来衡量、监控和比较性能， server response time, memory utilization, error rate, and more.

Instruments

创建以下Instruments来捕获测量值:

• 唯一名称, http.server.duration.
• instrument 类型, Histogram.
• 可选的度量单位, milliseconds or bytes.
• 可选说明.

Timeseries

单个 instrument 可以生成多个 timeseries. timeseries 是具有一组唯一属性的衡量指标，例如，每个主机都有用于同一衡量指标名称的单独时间序列。

Additive instruments

Additive or summable instruments 产生时间序列，当这些时间序列加在一起时，会产生另一个有意义且准确的时间序列。测量非递减数的加法仪器也称为单调（monotonic）.

例如，http.server.requests 是一个 additive timeseries ，因为您可以将来自不同主机的请求数相加以得到请求总数。

但是 system.memory.utilization利用率（百分比）不是累加的，因为来自不同主机的内存利用率总和没有意义 （90% + 90% = 180%)

Synchronous instruments

Synchronous instruments 与测量操作一起调用，例如，测量请求数，有新请求来调用 counter.Add(ctx, 1)，可以具有相关联的 Trace Context

对于同步仪器，加法仪器和分组仪器之间的区别在于，加法仪器产生可求和的时间序列 ，而分组仪器产生直方图

Instrument	Properties	Aggregation	Example
Counter	monotonic【递增】	sum -> delta	number of requests, request size、disk reads
UpDownCounter	additive	last value -> sum	number of connections、active requests、open connections、memory in use(megabytes)
Histogram	grouping	histogram	request duration, request size

Asynchronous instruments

Asynchronous instruments（observers）定期调用回调函数来收集测量结果，例如测量CPU使用率，不能具有相关联的 Trace Context

Instrument Name	Properties	Aggregation	Example
CounterObserver	monotonic	sum -> delta	CPU time
UpDownCounterObserver	additive	last value -> sum	Memory usage (bytes)
GaugeObserver	grouping	last value -> none/avg	Memory utilization (%percents)、error rate、cache hit rate

Choosing instruments

1. 如果您需要直方图、热图或百分位数 ，请使用Histogram.

2. 如果要通过记录增量值来计算某些内容：

   • 如果值是单调的，请使用Counter.
   • 否则，请使用UpDownCounter.

3. 如果要通过记录绝对值来测量某些内容：

   • 如果值是可加法/求和的：
     • 如果值是单调的，请使用CounterObserver.
     • 否则，请使用UpDownCounterObserver.
   • 如果该值不是可加/求和的，请使用GaugeObserver

4. Counter

   • synchronus、monotonic
   • the total number of processed requests、received bytes、disk reads
   • 对于Counter timeseries，后端通常计算增量并显示速率值，例如，per_min(http.server.requests) 返回每分钟处理的请求数

5. CounterObserver

   • asychronous、monotonic

6. UpDownCounter

   • sychronous、additive
   • the number of acitive requests、open connections、memory in use(megabytes)
   • 对于UpDownCounter timeseries，后端通常展示最后的值，但是不同timeseries可以累加在一起，例如，go.sql.connections_open返回打开连接的总数，go.sql.connections_open{service.name = myservice} 返回一项服务的打开连接数

7. UpDownCounterObserver

   • asychronous、additive

8. Histogram

   • sychronous、grouping
   • request latency、request size
   • 对于Histogram timeseries，后端展示百分位数、直方图或热图

9. GaugeObserver

   • asychronous、grouping
   • 非相加值，其和没有意义，error rate、memory utilization、cache hit rate
   • 对于GaugeObserver timeseries，后端暂时最后的值不允许不同timeseries求和

Metrics examples

明日待办

1. 继续学习Uptrace文档