- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
之前陆续写过一些和 OpenTelemetry 相关的文章:
这些内容的前提是最好有一些 OpenTelemetry 的背景知识,看起来就不会那么枯燥,为此这篇文章就来做一个入门科普,方便一些对 OpenTelemetry 不是那么熟的朋友快速掌握一些 OpenTelemetry 的基本概念.
早在 OpenTelemetry 诞生之前可观测性这个概念就一直存在了,我记得我最早接触到这个概念是在 16 年当时的公司所使用的一个产品:pinpoint 。
现如今这个项目依然比较活跃.
依然还记得当时通过它可以直接看到项目调用的拓扑图,在时间坐标上框出高延迟的点就能列出这些请求,同时还能查看此时的运行日志.
这样强大的功能对于一个刚工作一年的小白来说冲击力实属太大了一点.
后来才了解到 pinpoint 属于 APM 这类产品,类似的产品还有:
他们都是可以用于性能分析和链路追踪的产品,到后来公司的运维层面也接入过 Zabbix、open-falcon 之类的产品:
17之后全面切换到 spring boot 时,也用过社区提供的 spring-boot-admin 项目:
这就是一个简单的可以监控 spring boot 应用的产品,用于展示 JVM 指标,或者自己也可以定义一些健康指标.
再之后进入云原生体系后可观测性的技术栈稍有变化.
日志使用 Sidecar 代理的方式通过 Agent 将数据写入 ElasticSearch 中。 具体日志采集方式可以参考之前的文章:
而链路追踪则是使用的 skywalking,在 trace 这个领域 skywalking 还是非常受大家喜爱的.
不过最近也从 skywalking 切换到了我们本文所讲到的 OpenTelemetry,具体可以看之前的文章:
指标采集使用的是自然也是 Prometheus 的那一套技术栈,只是 Prometheus 换为了与它完全兼容的 VictoriaMetric 目前是为了更省资源.
客户端使用则是直接使用 Prometheus 的库进行指标暴露:
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>prometheus-metrics-core</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>prometheus-metrics-instrumentation-jvm</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>io.prometheus</groupId>
<artifactId>prometheus-metrics-exporter-httpserver</artifactId>
<version>1.0.0</version>
</dependency>
最终通过配置抓取策略,由 VictoriaMetrics 的 scrape 程序来抓取指标最终写入到它自己的存储中:
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMPodScrape
metadata:
name: kubernetes-pod-scrape
namespace: monitoring
spec:
podMetricsEndpoints:
- scheme: http
scrape_interval: "30s"
path: /metrics
relabelConfigs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
separator: ;
regex: "true"
replacement: $1
action: keep
# 端口相同
- action: keep_if_equal
source_labels: [ __meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_container_port_number ]
# 过滤INIT容器
- action: drop
source_labels: [ __meta_kubernetes_pod_container_init ]
regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
separator: ;
regex: (.+)
target_label: __metrics_path__
replacement: $1
action: replace
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
separator: ;
regex: ([^:]+)(?::\d+)?;(\d+)
target_label: __address__
replacement: $1:$2
action: replace
- separator: ;
regex: __meta_kubernetes_pod_label_(.+)
replacement: $1
action: labelmap
- source_labels: [__meta_kubernetes_namespace]
separator: ;
regex: (.*)
target_label: kubernetes_namespace
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_pod_name]
separator: ;
regex: (.*)
target_label: kubernetes_pod_name
replacement: $1
action: replace
vm_scrape_params:
stream_parse: true
namespaceSelector:
any: true
以上是 VM 提供的 CRD 。
到此铺垫完成,不知道有没有发现在可观测性中关键的三个部分:日志、指标、trace 都是使用不同的开源产品,从而会导致技术栈较多,维护起来自然也是比较麻烦的.
这么一个软件领域的核心能力自然需要提供一个完整方案的,将以上的不同技术栈都整合在一起,更加的方便开发者使用.
在这之前也有两个社区想要做类似的事情:
不过他们并没有统一整个可观测领域,直到 2019 年 CNCF 社区宣布成立 OpenTelemetry,并且将上述两个社区进行合并共同开发 OpenTelemetry.
背靠 CNCF 云原生社区加上许多知名厂商的支持(Google、Amazon、Redhat 等),现在已经正式成为 CNCF 的顶级项目了.
但我们打开 OpenTelemetry 社区的 GitHub 首页时,会看到有许多项目;第一反应应该是比较蒙的,下面我会着重介绍一些比较重要的项目.
在开始之前还是先简单介绍下 OpenTelemetry 的一些基础组件和概念:
整个 OpenTelemetry 系统其实可以简单分为三个部分:
第一个客户端很好理解,也就是我们的业务应用;如果是 Java 应用只需要挂载一个 agent 就可以自动采集系统的指标、链路信息、日志等上传到 Collector 中.
也就是上图的左边部分.
之后就是非常关键的组件 collector,它可以通过 OTLP 协议接收刚才提到的客户端上传的数据,然后再内部进行处理,最终输出到后续的存储系统中.
上图是 collector 的架构图 。
由于 OpenTelemetry 设计之初就是要做到厂商无关,所以它就得做出更高层级的设计.
关键点就是这里的 Receiver 和 Exporter 都是模块化的设计,第三方开发者可以基于它的标准开发不同组件从而兼容不同的产品.
Receiver:用于接收客户端上报的数据,不止是自己 agent 上报的数据,也可能会来自不同的厂商,比如 kubernetes、Kafka 等.
Exporter:同理,可以将 receiver 收到的数据进行处理之后输出到不同的组件中;比如 Kafka/Pulsar/Promethus/Jaeger 等.
比如我们可以使用 Nginx Receiver接收来着 Nginx 上报的数据.
使用 MySQL Receiver接收来自 MySQL 的数据.
当然通常我们使用最多的还是 OTLP Receiver,这是官方的 OTLP 协议的接收器,可以接受官方的一些指标,比如我们只使用了 Java Agent 进行数据上报时。 https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver 。
在这里是可以看到目前支持的所有第三方的 Receiver.
OpenTelemetry 所支持的 Exporter 也很多,比如一些常见的存储:
Exporter 的使用场景很多:如果是指标相关的数据可以直接写入 Prometheus,如果是日志数据也可以直接写入 ElasticSearch.
如果还有其他的特殊需求(删减属性等)则可以写入消息队列,自行处理完之后再发往 collector 进行后续的处理.
可能你已经发现了,由于 collector 非常的灵活,所以我们可以像搭积木一样组装我们的 receiver 和 exporter,它会以我们配置的流水线的方式进行调用,这样我们就可以实现任意可定制的处理逻辑.
而这些流水线的组装对于客户端来说都是透明的,也就是说 collector 的更改完全不会影响到业务;业务只需要按照 OTLP 的格式上报数据即可.
在之前的从 Skywalking 切换到 OpenTelemetry 的文章中有人问为什么要切换到 OpenTelemetry?
从这里也能看得出来,OpenTelemetry 的灵活度非常高,借助于 Exporter 可以任意的更换后端存储,或者增加/删减一些不需要的指标数据等.
当然我们也可以统一的在这里进行搜索,可以列出所有的第三方集成的组件: https://opentelemetry.io/ecosystem/registry/ 。
介绍完基本的概念后,我们可以看看 OTel 社区的一些主要开源项目.
这里我们还是以刚才的那个架构图从作往右讲起,也就是主要分为客户端和 collector 端.
目前官方支持的客户端语言已经非常齐全了,大部分的版本都已经是 Stable 稳定版,意味着可以进入生产环境.
这里我们以 Java 客户端为例: 其中我们重点关注下 opentelemetry-java 和 opentelemetry-java-instrumentation 这两个项目.
我们用的最多的会是 opentelemetry-java-instrumentation,它会给我们提供一个 java agent 的 JAR 包:
java -javaagent:path/to/opentelemetry-javaagent.jar \
-jar myapp.jar
我们只需要在 Java 应用中加上该 agent 就可以实现日志、指标、trace 的自动上报.
而且它还实现了不同框架、库的指标采集与 trace.
在这里可以查到支持的库与框架列表:
https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks 。
总之几乎就是你能想到和不能想到的都支持了.
而 opentelemetry-java 我们直接使用的几率会小一些,opentelemetry-java-instrumentation 本身也是基于它创建的,可以理解为是 Java 版本的核心基础库,一些社区支持的组件就可以移动到 instrumentation 这个库中.
比如我在上篇文章:从一个 JDK21+OpenTelemetry 不兼容的问题讲起中涉及到的 HostResourceProvider 资源加载就是从 opentelemetry-java 中移动到了 opentelemetry-java-instrumentation.
具体可以参考:https://github.com/open-telemetry/opentelemetry-java/issues/4701 。
之后就是 collector 的组件了,它同样的也有两个库: OpenTelemetry Collector 和 OpenTelemetry Collector Contrib 。
其实通过他们的名字也可以看得出来,他们的作用与刚才的 Java 库类似:
而我们生产使用时通常也是直接使用 opentelemetry-collector-contrib,毕竟它所支持的社区组件更多.
因为 OpenTelemetry 想要解决的是整个可观测领域的所有需求,所以仓库非常多,社区也很开放,感兴趣的朋友可以直接参与贡献,这么多 repo 总有一个适合你的.
后续会继续讲解如何安装以及配置我们的 OpenTelemetry.
参考链接:
最后此篇关于OpenTelemetry实践指南:历史、架构与基本概念的文章就讲到这里了,如果你想了解更多关于OpenTelemetry实践指南:历史、架构与基本概念的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
关闭。这个问题是off-topic .它目前不接受答案。 想改进这个问题? Update the question所以它是on-topic对于堆栈溢出。 10年前关闭。 Improve this qu
我正在开发一个 Android 应用程序。在此应用程序中, Logo 栏显示在所有页面( Activity )上,或者我们可以说它在所有页面上都有标题。这个 Logo 栏有几个图标,如主页、登录、通知
我正在使用 hadoop 使用开源接口(interface) HVPI 处理视频。然而,inputsplit 的实现,更准确地说是在 isSplitableobContext (context, Pa
1. 是什么? MySQL 是最流行的关系型数据库管理系统,在 WEB 应用方面 MySQL 是最好的 RDBMS(Relational Database Management System
有没有办法使用 c++20s 的概念来检查一个值是否满足某些要求? 假设我正在编写某种使用分页的容器,并且我想让页面大小成为模板参数。 template class container; 我可以使用带
如何在 ArrayList 中循环遍历 ArrayList? 例如,如果我有一个名为 Plants of Plant 对象的 ArrayList。每个 Plant 对象内部都有一个随机数量的花名。我如
如何在UML类图中绘制C++概念? 具体来说,我有以下代码: template concept Printable = requires(T a, std::ostream &where) {
我有兴趣制作一个网站,在访问者访问时闪现整个网络历史记录。我计划使用 JavaScript 来获取每个观看者计算机上的历史记录,并根据他们拥有的内容以不同的速度对其进行动画处理。我的想法是使用 his
有一个模板定义,例如: template void foo( void ) { /* ... */ } 如何定义一个概念,以便N必须为非零正值(N> = 1)? 就像是: template con
封装是信息隐藏还是导致信息隐藏? 正如我们所说,封装将数据和函数绑定(bind)在单个实体中,因此它为我们提供了对数据流的控制,并且我们只能通过一些定义良好的函数来访问实体的数据。因此,当我们说封装导
下面有一个简单的代码片段,它使用以下方式进行编译: g++-9 -std=c++2a -fconcepts 这是试图定义一个需要存在函数的概念。我希望输出是"is",但事实并非如此……知道为什么吗?谢
我有一个普通二元运算符的概念 template concept is_binary_operation = requires (const T& t1, const T& t2) // e.g
我正在c++ 20中实现具有启发式功能的搜索算法。 我试图用类似这样的概念来约束我的算法可以使用的功能: template concept Heuristic = requires(SelfType
我需要了解 SAS 如何读取/执行数据步骤。当我查找有关 SAS 如何读取数据步骤的信息时,我似乎只找到有关它如何读取以进行合并的信息,我不了解与常规数据步骤相关的信息。比方说,我有这行代码: dat
最近我看到一个关于“框架”的问题,如果“框架”有不同的类型或概念。那么,存在不同“类型”的“框架”吗? 例如:NodeJS 是一种“类型”(概念),而 Hibernate ORM 是另一种“类型”(概
如何使用任何技术禁用或清除客户端浏览器 Cookie 我认为使用 javascript 可以用于任何技术 最佳答案 var cookies = document.cookie.split(";");
我正在使用 target = "_blank" 单击链接时生成新选项卡。但是,浏览器会将焦点移至该选项卡。 有没有办法让焦点保持在当前标签页上? 回答摘要 基本上,只需发送一个模拟控件点击的当前事件。
我正在尝试在我的 android/firebase(cloud firestore) 应用程序上添加一项需要其他用户批准/拒绝的功能。例如,当 Air&BnB 上的用户想要预订一个地方时,所有者必须批
这个问题在这里已经有了答案: mysql_fetch_array()/mysql_fetch_assoc()/mysql_fetch_row()/mysql_num_rows etc... expec
public class MyClass { public static void main(String[] args) { System.out.println("Hell
我是一名优秀的程序员,十分优秀!