包含标签 可观测性 的文章

OpenTelemetry 101:面向 IT 领导者和爱好者的非技术指南

OpenTelemetry 是一个开源项目,旨在标准化遥测数据的收集和处理。通过提供一组 API、库和代理,OpenTelemetry 使开发人员能够收集、处理和可视化来自应用程序、服务和系统的遥测数据。

什么是 OpenTelemetry?日志、指标、跟踪的开源标准

OpenTelemetry 是一个开源可观测性框架,旨在提供统一的标准和工具,以便开发人员可以轻松地收集、生成、收集和导出遥测数据。这些数据包括日志、指标和跟踪,这些数据对于了解应用程序和基础设施的执行情况至关重要
什么是 OpenTelemetry?日志、指标、跟踪的开源标准

Flashcat 产品介绍

Flashcat 是基于开源夜莺(Nightingale)实现的统一可观测性产品,同时针对稳定性保障场景做了大量的增强。目前 Flashcat 已经得到了众多开源和商业用户的认可和使用。本文将介绍 Flashcat 都解决了哪些问题,用了哪些方法。
Flashcat 产品介绍

什么是可观测性?可观测性成功指南

可观察性是一种方法,可以帮助您预测和预防未来的问题。它有助于根据外部输出的知识确定系统的状态。本文将详细介绍可观测性的定义、重要性、好处、挑战、支柱及其如何运作。
什么是可观测性?可观测性成功指南

科普:可观测性与传统监控的区别和联系

随着技术架构的不断演进以及云原生、微服务理念的广泛推广,可观测性(Observability)概念逐渐崭露头角,成为提升系统稳定性和运维效率的关键技术。本文将探讨可观测性与传统监控之间的区别与联系,介绍快猫星云在可观测性领域所提供的先进服务。
科普:可观测性与传统监控的区别和联系

初学者指南:可观测性是什么?

可观测性,顾名思义,指的是系统状态能够被观察与度量的特性。在信息技术领域,可观测性被精确定义为根据系统生成的输出数据(涵盖日志、指标及跟踪信息)来测量和理解系统当前状态的能力。
初学者指南:可观测性是什么?

科普:阐释什么是可观测性

随着云原生技术的广泛应用,可观测性作为云原生运维的核心工具,正成为事件管理实践中的关键支撑。本文探讨可观测性的本质、来源、发展、重要性及其实施路径。
科普:阐释什么是可观测性

科普:一文理解可观测性

可观测性一词之所以在近两年迅速走红,很大程度上得益于 CNCF 在云原生定义中明确提到 Observerbility,并将其视为云原生时代的必备能力。
科普:一文理解可观测性

科普:可观测性是什么? 有哪些入门知识需要了解?

在复杂的服务器运维环境中,可观测性(Observability)是确保系统稳定运行、及时发现并解决问题的关键。这一概念核心通过系统输出的数据—如日志、指标及链路追踪—来精准衡量并理解当前系统的运行状态。
科普:可观测性是什么? 有哪些入门知识需要了解?

开源时序库的兴起以及未来发展的观点

本文是 VictoriaMetrics 公司创始人所著,探讨了开源时序库的兴起历史、值得关注的项目以及未来的发展方向。时序库是监控、可观测性领域的基础设施,如果您是基础设施方向的工程师,尤其值得关注。
开源时序库的兴起以及未来发展的观点

无需推翻既有的建设,这个可观测性产品思路清奇

市面上已经有很多开源、商业的可观测性类产品,比如 Zabbix、Prometheus、Nightingale、SigNoz、SkyWalking、ELK 等等,而且各类云厂商也会提供自己的可观测性套件,有些规划混乱的云厂商甚至会提供功能重叠的多套产品,这加剧了企业数据孤岛的现状。怎么解?
无需推翻既有的建设,这个可观测性产品思路清奇

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

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

监控都没做好,你还要可观测性...

很多公司听说可观测性好,就要上马可观测性项目,自研/采购,各种投入,结果发现效果很差,业务不认可,最终一地鸡毛
监控都没做好,你还要可观测性...

OpenTelemetry Logging 思维导图,收藏

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

OpenTelemetry Tracing 思维导图,收藏

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

理想的监控系统到底是什么样的?

笔者从 14 年开始做监控,到现在接近 10 年,认知在持续迭代,最近又有一些新想法,跟大家分享一下我眼中的理想的监控系统到底是什么样的
理想的监控系统到底是什么样的?

可观测性与传统监控的区别和联系

什么是可观测性?相比传统监控,可观测性是“新瓶装旧酒”吗?他们有哪些区别和联系,从传统监控到可观测性,Gap 到底有多大?
可观测性与传统监控的区别和联系

使用 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 构建可观测性 03 - 导出

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

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

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

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

开源的Datadog?可观测性平台SigNoz是否名副其实?

SigNoz号称自己是开源领域的Datadog,基于OpenTelemetry做了一套可观测性方案。夜莺从V6版本开始,也希望做全栈可观测性方案,巧了,大家目标一致,今天我们一起来对SigNoz做个初步了解,看看其产品设计如何,也帮大家未来选型做参考。
开源的Datadog?可观测性平台SigNoz是否名副其实?

可观测性是什么? 入门指南

如果您之前对可观测性重要性,益处,以及组成不甚了解,本文是一个合适的指南手册
可观测性是什么? 入门指南

面向故障处理的可观测性体系建设

可观测性不能只关注 metrics、logging、tracing 这些 raw data,还要能够从数据中提取特征,进而推导出观点,最终辅助洞察定位故障。能够辅助定位故障才是可观测性的核心目标,构建数据只是建设底座,离目标还差的很远,千万不要觉得有了数据,就完活了。
面向故障处理的可观测性体系建设

可观测性三支柱?远不止此!

日志,指标和分布式链路追踪这三个可观测性的传统支柱,已经是过时的,过于关注数据采集和底层数据格式,而不去关注结果(我们建设可观测性的初心和目标),这个做法实在是滑天下之大稽
可观测性三支柱?远不止此!

从监控系统到可观测平台的演进之路

可观测性(Observability)是一种软件开发和系统构建的哲学,是对系统内部状态及行为的度量和推断能力,通常包括日志、指标、链路追踪等多个度量维度。也就是说,在软件开发和运维领域中,可观测性是指对于一个复杂的系统,能够通过监控、日志、指标、追踪等手段,快速地发现、诊断、解决问题的能力。
从监控系统到可观测平台的演进之路

如何做好今天的运维

优秀的运维和架构师应该是怎样的?运维能给人工智能时代带来价值吗?
如何做好今天的运维

基于方法论实现的Flashcat监控有哪些设计上的理念和方法?

Flashcat的设计初衷是实现一个从数据到平台到场景真正一体化的统一监控,成为服务稳定性保障,特别是故障处理的真帮手。
基于方法论实现的Flashcat监控有哪些设计上的理念和方法?

标签
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 mongodb mongodb监控 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