论文阅读 《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》

背景 在我们内部产品中,一直有关于网络性能数据监控需求,我们之前是直接使用 ping 命令收集结果,每台服务器去 ping (N-1) 台,也就是 N^2 的复杂度,稳定性和性能都存在一些问题,最近打算对这部分进行重写,在重新调研期间看到了 Pingmesh 这篇论文,Pingmesh 是微软用来监控数据中心网络情况而开发的软件,通过阅读这篇论文来学习下他们是怎么做的。

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

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

夜莺中心端管理categraf采集规则并下发

市面上常见的采集器,比如 telegraf、grafana-agent、datadog-agent 等,通常内置了多种采集插件,比如可以采集操作系统的常规指标,也可以采集 mysql、redis、mongodb、kafka、elasticsearch、jmx 等指标,但是具体要采集什么数据,通常需要在客户端采集器上进行配置,修改采集器的配置文件,比较麻烦,尤其是对于一些不太容易登录的机器,这个操作就更难实现了。

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

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

使用 eBPF 在云中实现网络可观测性

可观测性是一种了解和解释应用当前状态的能力,也是一种知道何时出现问题的方法。随着在 Kubernetes 和 OpenShift 上以微服务形式进行云部署的应用程序越来越多,可观察性受到了广泛关注。许多应用程序都有严格的承诺,比如在停机时间、延迟和吞吐量方面的 SLA,因此网络层面的可观测性是一项非常必要的功能。网络层面的可观测性由不同的编排器提供,有的是内置支持,有的是通过插件和 operator 提供。 最近,eBPF(扩展的伯克利数据包过滤器)因其性能和灵活性成为在终端主机内核实现可观察性的热门选择。通过这种方法,可以在网络数据路径的某些点(如套接字、TC 和 XDP)上挂接自定义程序。目前已发布了多个基于 eBPF 的开源插件和 operator,每个插件和 operator 都可插入终端主机节点,通过云上的编排器提供网络可观察性。

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

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

夜莺项目发布v6.0.2版本,增强日志查看能力

夜莺项目发布v6.0.2版本,增强日志查看能力,提升大盘排错能力,订阅规则支持订阅业务组,仪表盘页面支持调试功能,优化Loki数据源校验逻辑。

可观测性平台夜莺开源项目发布V6正式版!

夜莺开源项目在2023.7月底发布了V6版本,这个版本开始,项目目标不止于做一款开源监控系统,而是要做一款开源可观测性平台,不过路漫漫其修远兮,初期只是把日志数据源引入并完成了基本的可视化,后续会着力打通指标和日志的数据串联以及数据特征提取。欢迎小伙伴一起参与共建。

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

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

纯粹的干货分享,CCF夜莺·2023可观测性论坛完满收官

各类技术大会越来越多,但是干货越来越少,有的大会基本全是乙方在推广产品,而且,只是吹嘘如何如何厉害,却不讲思路理念,对与会者裨益甚少。CCF夜莺·2023可观测性峰会,大量价值信息输出,好评如潮。
开源版
Flashcat
Flashduty