芜湖商城网站建设,wordpress前端页面,成都鱼羊环保网站制作设计,wordpress头像自定义今日已办
OpenTelemetry Logs
通过日志记录 API 支持日志收集
集成现有的日志记录库和日志收集工具
Overview
日志记录 API - Logging API#xff0c;允许您检测应用程序并生成结构化日志旨在与其他 telemerty data#xff08;例如metric和trace#xff09;配合使用允许您检测应用程序并生成结构化日志旨在与其他 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_id958180131ddde684c1dbda1aeacf51d3 span_id0cf859e4f7510204New first-party logs
附加上下文信息到日志条目例如标签、属性或元数据。记录不同级别的事件或消息例如调试、信息、警告、错误等。标准化跨分布式系统传播日志中的上下文。
OpenTelemetry Collector
灵活且可扩展的代理收集、处理和导出 telemetry data简化从多个来源接收和管理 telemetry data 导出到多个后端或可观测系统。支持多种日志源包括应用程序日志、日志文件、日志库和第三方日志系统。集成流行的日志框架和库从而实现日志数据的无缝摄取。提供转换和丰富日志数据的能力。可以修改日志属性、添加元数据或使用其他上下文信息丰富日志以增强分析和故障排除的价值。收集和处理后将日志数据导出到各种日志记录后端或系统。支持将日志导出到流行的日志平台、存储系统或日志管理 用于长期存储、分析和可视化的工具
OpenTelemetry Backend
将日志数据导出到日志后端后可以使用平台的功能处理和分析日志。包括过滤、搜索、聚合和可视化日志以深入了解应用程序的行为并解决问题。
Sampling and rate-limiting
采样 Sampling 通过减少创建sampledSpan 的数量来降低 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 ; 以局部计算的概率来推算、估计整体。
NameSideAdjusted countAccuracyHead-based samplingClient-sideYes100%Rate-limiting samplingServer-sideYes90%Tail-based samplingServer-sideYes90%
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 等接收通知。
明日待办
组会汇总进度和问题继续学习文档
