包含标签 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 监控微服务

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

OpenTelemetry Logging 思维导图,收藏

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

OpenTelemetry Tracing 思维导图,收藏

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

使用 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 - 介绍

标签
aiops alertmanager apache apiserver apm categraf catpaw ccf chatgpt chatops clickhouse controller-manager coredump cprobe cslo datadog devops dns docker ebpf elasitcsearch elastalert elasticsearch etcd etl flashcat flashduty flashduty-changelog fluentbit fluentd gdpr gitops golang google grok_exporter hadoop hana haproxy hdfs httpstat iac ibex ilo im协同 it监控 jaeger jenkins jmx-exporter jolokia kafka kibana kube-proxy kube-state-metrics kubelet kubernetes linkedin linux log log-monitor logging logs loki metrics metricsql mimirtool monitoring mtail mysql netflix nightingale node-exporter nsenter observability on-call oncall open-falcon open-telemetry openmetrics opentelementry opentelemetry oracle监控 otel pagerduty pingmesh postgresql product-feature prometheus prometheus告警 promql promxy rancher redis salt scheduler signoz skywalking sla sli slo snmp snmp-exporter spanconnector sre telegraf tidb traces tracing troubleshooting uber ulimit vector victorialogs victoriametrics zabbix 北极星 不可变基础设施 出海 错误预算 错误预算机制 滴滴夜莺 钉钉 飞书 服务稳定性 告警 告警oncall 告警风暴 告警降噪 告警聚合 告警排班 告警认领 告警升级 告警事件 告警收敛 告警通知 告警响应 告警协同 告警抑制 告警引擎 告警值班 告警指派 告警自愈 根因定位 故障管理 计算机学会 架构师 监控 监控agent 监控方法论 监控工具 监控设计思考 监控系统 监控系统合规 开源 开源监控 开源夜莺 可观测平台 可观测性 可观测性论坛 可观测性体系建设 客户案例 快猫 快猫星云 链路追踪 灭火图 企业微信 人工智能 日志 日志存储 日志分析 日志告警 日志监控 容器 时序库 时序数据库 事件监控 手把手构建生产级监控系统 提问的智慧 统一监控 网络可观测性 网络排障 稳定性保障 稳定性方法论 稳定性体系 稳定性体系建设 信创 业务监控 夜莺 夜莺黄埔营 夜莺监控 夜莺开发者创新论坛 夜莺开源项目 夜莺用户案例 医药健康 仪表盘 用户案例 云厂商 云原生监控 云原生组织 运维 运维百家讲坛 运维告警 运维监控 运维监控系统 运维监控系统实战笔记 智能告警 自监控
快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat