所属分类 OpenTelemetry专栏 的文章

OpenTelemetry Logging 思维导图,收藏

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

OpenTelemetry Tracing 思维导图,收藏

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

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

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

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

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

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

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

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

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

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

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

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

毫无疑问,在过去几年里,你可能已经多次听到过可观测性这个词。对于很多人来说,很难理解这个词的真正含义。对许多人来说,他们错误地将其等同于"监控"。虽然可观测性的根本定义以及它所包含的一切都不在本系列博文的讨论范围之内,但我强烈建议您购买一本由 Charity Majors (twitter)、Liz Fong-Jones (twitter) 和 George Miranda (twitter) 合著的《可观测性工程》(Observability Engineering)一书。
标签
aiops apiserver apm categraf catpaw ccf chatgpt chatops clickhouse controller-manager coredump cprobe cslo devops dns docker ebpf elastalert elasticsearch etcd etl flashcat flashduty flashduty-changelog gitops golang google grok_exporter hadoop haproxy hdfs iac ilo im协同 jaeger jmx-exporter jolokia kafka kube-proxy kube-state-metrics kubelet kubernetes linkedin linux log log-monitor logging logs metrics metricsql mimirtool monitoring mtail mysql netflix nightingale node-exporter nsenter observability oncall open-falcon openmetrics opentelemetry oracle监控 otel pingmesh postgresql product-feature prometheus prometheus告警 promql promxy rancher salt scheduler signoz skywalking sli slo snmp snmp-exporter sre telegraf tidb traces troubleshooting uber ulimit vector victorialogs victoriametrics zabbix 北极星 不可变基础设施 错误预算 错误预算机制 滴滴夜莺 钉钉 飞书 服务稳定性 告警风暴 告警降噪 告警聚合 告警排班 告警认领 告警升级 告警协同 告警抑制 告警引擎 告警指派 告警自愈 根因定位 故障管理 计算机学会 架构师 监控 监控agent 监控设计思考 监控系统 开源 开源监控 开源夜莺 可观测性 可观测性论坛 可观测性体系建设 快猫 快猫星云 灭火图 企业微信 人工智能 日志分析 日志告警 容器 事件监控 手把手构建生产级监控系统 提问的智慧 网络可观测性 稳定性保障 稳定性方法论 稳定性体系 稳定性体系建设 信创 业务监控 夜莺 夜莺黄埔营 夜莺监控 夜莺开源项目 夜莺用户案例 医药健康 仪表盘 用户案例 云厂商 云原生监控 云原生组织 运维 运维百家讲坛 运维监控 运维监控系统实战笔记 智能告警 自监控
开源版
Flashcat
Flashduty