OpenTelemetry

OpenTelemetry 是一个开放的、可扩展的框架,旨在为云原生应用提供统一的监控、追踪和日志记录功能。它是由 Cloud Native Computing Foundation (CNCF) 管理的,旨在为开发者提供跨语言、跨平台的可观察性解决方案。OpenTelemetry 是一个强大的可观察性框架,提供统一的追踪、度量和日志收集功能,帮助开发者更好地理解和监控其应用程序的行为。通过使用 OpenTelemetry,团队能够提升系统的可观察性,从而提高可靠性和性能。

手把手教程:利用 OpenTelemetry 监控微服务

针对一个完整的微服务系统,如何利用 OpenTelemetry 快速搭建一个覆盖数据采集、收集、存储、展示、分析全流程的可观测性系统,crossoverJie 撰写的教程,值得仔细阅读。
手把手教程:利用 OpenTelemetry 监控微服务

OpenTelemetry Collector 部署方式的选择

介绍 OpenTelemetry Collector 的部署方式,包括 sidecar 模式、daemonset 模式和中心集群模式。不同的部署方式适用于不同的场景,需要根据实际情况选择合适的部署方式。
OpenTelemetry Collector 部署方式的选择

科普:什么是 OpenTelemetry

OpenTelemetry 是一个用于分布式系统的观测性框架,旨在提供可观测性数据(如追踪、度量和日志)的统一标准和工具。它是由 OpenTelemetry 工作组开发的,结合了 OpenTracing 和 OpenCensus 两个项目的优势。
科普:什么是 OpenTelemetry

OpenTelemetry 和 Fluent Bit 集成,入门教程

通过将 OpenTelemetry Collector 与 FluentBit 集成,用户可以简化其可观察性,并为日志、指标和跟踪创建高效、可扩展的数据管道。通过提供的配置文件和 Docker Compose 设置,开始使用这个强大的组合变得简单明了。
OpenTelemetry 和 Fluent Bit 集成,入门教程

使用 SpanMetrics Connector 将 OpenTelemetry 跟踪转换为指标

如果您已经实施了跟踪但缺乏强大的指标功能怎么办? SpanConnector 是一个通过将跟踪数据转换为可操作指标来弥补这一差距的工具。这篇文章详细介绍了 SpanConnector 的工作原理,提供了有关其配置和实现的指南。
使用 SpanMetrics Connector 将 OpenTelemetry 跟踪转换为指标

OpenTelemetry Tracing 思维导图,收藏

相较于传统的单体应用,以及过去相对静态化的基础设施,现代的应用架构,是一种松耦合的、动态变化的、数量巨大的微服务构成的网络。为了看清楚网络中众多不同的服务之间的依赖关系,以及看清楚一次请求经过的路径上各个节点之间的耗时等信息,传统监控,已经无力应对了。这个网络的每个节点,都有可能是出问题的风险点,tracing 能够追踪每个请求在全生命周期过程中所经过的每个节点的信息,成为了云原生时代和微服务架构下构建可观测体系的关键一环。
OpenTelemetry Tracing 思维导图,收藏

OpenTelemetry Logging 思维导图,收藏

Logs 是“可观测性三支柱”中历史包袱最重的监控数据类型,日志的格式更随意,缺乏标准和规范。推荐在应用研发阶段,按照 OTel Logs 规范打印日志。
OpenTelemetry Logging 思维导图,收藏

使用 OpenTelemetry 构建可观测性 06 - 生态系统

过去的五篇文章讨论了如何使用 OpenTelemetry 来构建可观测性的技术细节。我认为在本博文系列的结尾介绍有关 OTel 生态系统的信息,为读者提供更全面的了解非常重要。OpenTelemetry 的发展非常迅速,对于刚接触它的人来说,可能会感到有些不知所措或困惑,不知道在哪里找到有效的信息或资源。 OpenTelemetry 是一个 CNCF 项目。但是,在 CNCF 项目中 OpenTelemetry 的表现如何?以拉取请求、问题和提交代码的数量来衡量,OpenTelemetry 是第二活跃的 CNCF 项目,仅次于 Kubernetes:
使用 OpenTelemetry 构建可观测性 06 - 生态系统

使用 OpenTelemetry 构建可观测性 05 - 传播和行李(Propagation & Baggage)

我们开发的应用程序可能具有不同的形态和架构:有些是单体应用,有些是微服务。为单体应用程序添加遥测数据相对来说简单,因为所有数据都在同一进程中。然而对于微服务应用程序,情况可能会更具挑战性。 通常,分布式微服务应用程序的不同服务之间仅通过网络连接。然而,当我们想要创建有效的链路追踪数据,就要考虑到下面的问题: 即使是微服务应用程序,我们也希望观察到从开始到结束的用户路径,这意味着跨越多个服务的边界。这就是我们所说的分布式链路追踪。不过我们如何实现这一点呢?我们如何使链路追踪信息贯穿可能是分布在多个进程,并且是不同的基础架构上呢? 传播( propagation ) 在 OpenTelemetry 中,解决这个挑战的方案是通过传播来实现。这意味着以某种方式将链路追踪 ID(和父跨度 ID)传递给被调用服务,以便它们可以将该信息添加到分布式链路追踪路径中的一个跨度上。下面是一个示意图:
使用 OpenTelemetry 构建可观测性 05 - 传播和行李(Propagation & Baggage)

使用 OpenTelemetry 构建可观测性 04 - 收集器

在之前的博文中,我们讨论了如何使用 SDK 和链路追踪生产者来导出进程中的遥测数据。尽管有多种类型的导出器可供选择,但其中一个常见的目标是将数据导出到 OpenTelemetry Collector。本篇文章将深入探讨收集器以及如何使用它。 选 OTel Collector 还是其他 正如上一篇博客文章中提到的,我谈到了使用 OTLP 导出器将数据发送到 OTel Collector。此外我还提到,对导出器来说输出遥测数据的目的地是多样的。当导出器可以直接发送到 Jaeger、Prometheus 或控制台时,为什么还要选择 OTel Collector 呢?答案是由于灵活性:
使用 OpenTelemetry 构建可观测性 04 - 收集器

使用 OpenTelemetry 构建可观测性 03 - 导出

上一个博文中,我提到如何使用 OpenTelemery 的特定语言 API 来收集遥测数据,包含手动和自动的埋点技术,这很重要!但是,收集遥测数据只是解决方案的第一步。 你需要把遥测数据路由转发到其他地方,同时添加额外的元数据信息。这时就轮到 SDK 发挥作用了。 链路追踪生产者( Tracer Provider ) 链路追踪生产者是 SDK 中一个关键概念。用于将通过 API 收集的遥测数据与其他组件联系起来。在 Go 语言中,TracerProvider 对象只有一个 Tracer 方法的接口,方法签名如下:

使用 OpenTelemetry 构建可观测性 02 - 埋点

这是讲解 OpenTelemetry 系列博客的第二篇。在上一篇博客中,我们介绍了 OpenTelemetry 是什么以及由什么组成。现在我们将讨论如何使用 OTel 准确收集遥测数据和链路追踪数据。 手动埋点 我们这里谈论“埋点”(代码插桩),是指通过技术手段采集链路追踪数据的行为。通常有两种方式:手动和自动(下面讨论)。顾名思义,手动埋点需要在软件中显式的选择要暴露哪些数据。 手动埋点被认为是更高级和定制的遥测方法。手动和自动埋点分别有各自的使用场景,我们将在下文介绍。
使用 OpenTelemetry 构建可观测性 02 - 埋点

使用 OpenTelemetry 构建可观测性 01 - 介绍

毫无疑问,在过去几年里,你可能已经多次听到过可观测性这个词。对于很多人来说,很难理解这个词的真正含义。对许多人来说,他们错误地将其等同于"监控"。虽然可观测性的根本定义以及它所包含的一切都不在本系列博文的讨论范围之内,但我强烈建议您购买一本由 Charity Majors (twitter)、Liz Fong-Jones (twitter) 和 George Miranda (twitter) 合著的《可观测性工程》(Observability Engineering)一书。
使用 OpenTelemetry 构建可观测性 01 - 介绍

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat