SDK 设计在之前提到了cim在做集成测试的时候遇到的问题，需要提供一个 SDK 来解决，于是我花了一些时间编写了 SDK，同时也将 cim-client 重构了。重构后的代码长这个样子：12345678910111213141516171819202122@BeanpublicClientbuildClient(@Qualifier("callBackThreadPool")ThreadPoolExecutor callbackThreadPool,Event event){OkHttpClientokHttpClient=newOkHttpClient.Builder().connectTimeout(3, TimeUnit.SECONDS).readTimeout(3, TimeUnit.SECONDS).writeTimeout(3, TimeUnit.SECONDS).retryOnConnectionFailure(true).build();returnClient.builder().auth(ClientConfigurationData.Auth.builder().userName(appConfiguration.getUserName()).userId(appConfiguration.getUserId()).build()).routeUr ...继续阅读 (2)

背景最近这段时间在处理一个StarRocks的关于物化视图优化的一个问题，在此之前其实我也没有接触过StarRocks这类主要处理数据分析的数据库，就更别提在这上面做优化了。在解决问题之前我先花了一两天时间熟悉了一下StarRocks的一些概念和使用方法，然后又花了一些时间搭建环境然后复现了该问题。之后便开始阅读源码，大概知道了相关代码的执行流程，但即便是反复阅读了多次代码也没有找到具体出现问题的地方。所以便考虑在本地 Debug 源码，最终调试半天之后知道了问题所以，也做了相关修改，给社区提交了 PR，目前还在推进过程中。环境搭建这里比较麻烦的是如何在本地 debug 代码。根据官方的架构图会发现StarRocks主要分为两个部分：FE：也就是常说的前端部分，主要负责元数据管理和构建执行计划。BE：后端存储部分，执行查询计划并存储数据。其中 FE 是 Java 写的，而存储的 BE 则是 C++ 写的，我这次需要修改的是 FE 前端的部分，所以本篇文章主要讨论的是 FE 相关的内容。好在社区已经有关于如何编译和构建源码的教程，这里我列举一些重点，FE 首先需要安装以下一些工具：ThriftProtobufPython3JDK8+12345brew install alberttwong/thrift/thrift@0.13$ thrift -versionThrift versi ...继续阅读 (1)

最近有时间又把以前开源的IM 消息系统捡起来继续开发了（确实这些年经常有朋友催更）。没错，确实是这些年，因为上次发版还是再 2019 年的八月份。这段时间比较重大的更新就是把元数据中心抽离出来了，以前是和 zookeeper 的代码强耦合在一起的，重构之后可以有多种实现了。今后甚至可以提供一个 jar 包就可以把后端服务全部启动起来用于体验，此时就可以使用一个简单的基于内存的注册中心。除此之外做的更多的就是新增了一个集成测试的模块，没有完善的集成测试功能在合并代码的时候都要小心翼翼，基本的功能需求都没法保证。加上这几年我也接触了不少优秀的开源项目（比如 Pulsar、OpenTelemetry、HertzBeat 等），他们都有完整的代码合并流程；首先第一点就得把测试流水线跑通过。这一点在 OpenTelemetry 社区更为严格：他们的构建测试流程非常多，包括单元测试、集成测试、代码风格、多版本兼容等。所以在结合了这些优秀项目的经验后我也为 cim 项目新增相关的模块cim-integration-test，同时也在 github 上配置了相关的 action，最终的效果如下：在“Build with Maven”阶段触发单元测试和集成测试，最终会把测试结果上传到 Codecov，然后会在 PR 的评论区输出测试报告。相关的 action 配置如下：就是配置了几个 Job，重点是 ...继续阅读 (5)

背景因为公司内部在使用PowerJob作为我们的分布式调度系统，同时又是使用 OpenTelemetry 作为可观测的底座，但目前 OpenTelemetry 还没有对 PowerJob 提供支持，目前社区只对同类型的 XXL-JOB 有支持。恰好公司内部也有一些开发同学有类似的需求：于是在这个背景下我便开始着手开发 PowerJob 的 instrumentation，最终的效果如下：从这个链路图中可以看到 grpc-consumer 提供了调度的入口函数，然后在内部发送了 Pulsar 消息，最终又调用了 grpc-provider 的gRPC接口。这样就可以把整个链路串起来，同时还能查看PowerJob调度的 JobId、以及调用参数等数据，这样排查问题时也更加直观。开发 Instrumentation 的前置知识在正式开发 Instrumentation 之前还需要了解一些前置知识点。这里我们以现有的gRPC和我编写的 PowerJob instrumentation 为例，可以看到gRPC的 instrumentation 中多了一个 library 的模块。这里就引申出了两种埋点方式：Library instrumentationJava agent instrumentation通常我们对一个框架或者一个库进行埋点时，首先需要找到它的埋点入口。以grpc为例，我们首先 ...继续阅读 (15)

23 年在 ChatGPT 刚出来的时候就在V 站上看到有一个看到有大佬用自己的微信聊天记录和博客文章生成了一个 AI 替身：当时就想着自己做一个，不过当时实现起来还比较复杂，直到如今 AI 已经越来越普及，想做一个自己的 AI 替身成本也非常低了。于是就有了下图里的效果：和自己的内容这么对话还挺有意思的，现在大家就可以直接在我公众号回复消息和”他“聊天。也可以通过小程序来使用：如何搭建这里使用的数据源全都是我发布在公众号里的 260 篇文章。能够直接获取到微信公众号的数据一定是腾讯自己的产品，其实这个产品叫做：腾讯元器，是腾讯大模型团队基于混元大模型推出的智能创作工具。我们可以自定义 prompt、数据源、插件来实现自己的 AI 机器人，或者类似的交互产品。直接创建一个智能体，然后编写对应的提示词即可，使用起来非常简单，官方也提供了一些prompt的示例：根据自己的需求来填写就可以了。最主要的还是创建一个知识库，也就是你的数据源，好在这里直接整合了公众号的数据；直接授权就可以使用，同时还可以每天定时更新，非常方便。它会根据你的问题来判断是否用知识库的内容来回答，所以即便是问一些知识库不存在的内容也能拿到结果。除此之外还可以上传你本地的文件，所以即便是你没有写公众号也可以上传自己整理的内容。有兴趣的朋友可以试试尝尝鲜，后续我可以持续完善这个知识库，比如输入一些代码，之后再有向我咨询 ...继续阅读 (4)

可观测性概念当一个软件或系统出于运行状态时，如果我们不对他加以观测，那它的运行状态对我们来说就是一个黑盒。如上图所示。我们只能通过业务的表象来判断它是否正常运行，无法在故障发生前进行预判，从而只能被动解决问题。这类问题在微服务时代体现的更加明显，即便是业务已经出现问题，在没有可观测性系统的前提下想要定位问题更是难上加难。好在可观测性这个概念由来已久，已经由一些业界大佬抽象出几个基本概念：Logs：离散的日志信息Metrics：聚合的指标Trace：请求基本的链路追踪结合这三个指标，我们排查问题的流程一般如下：首先根据 metrics 来判断是否有异常，这点可以通过在 Prometheus 的 AlertManager 配置一些核心的告警指标。比如当 CPU、内存使用率超过 80% 或者某个应用 Down 机后就发出告警。1234567891011121314groups:-name:AllInstancesrules:-alert:InstanceDown# Condition for alertingexpr:up==0for:1m# Annotation - additional informational labels to store more informationannotations:title:'Instance{{ $labels.i ...继续阅读 (5)

前言在前面两篇实战文章中：OpenTelemetry 实战：从零实现分布式链路追踪OpenTelemetry 实战：从零实现应用指标监控覆盖了可观测中的指标追踪和metrics监控，下面理应开始第三部分：日志。但在开始日志之前还是要先将链路追踪和日志结合起来看看应用实际使用的实践。通常我们排查问题的方式是先查询异常日志，判断是否是当前系统的问题。如果不是，则在日志中捞出trace_id再到链路查询系统中查询链路，看看具体是哪个系统的问题，然后再做具体的排查。类似于这样：日志中会打印trace_id和span_id。如果日志系统做的比较完善的话，还可以直接点击trace_id跳转到链路系统里直接查询链路信息。MDC这里的日志里关联 trace 信息的做法有个专有名词：MDC:(Mapped Diagnostic Context)。简单来说就是用于排查问题的上下文信息，通常是由键值对组成，类似于这样的数据：12345678910111213{"timestamp":"2024-08-05 17:27:31.097","level":"INFO","thread":"http-nio-9191-exec-1","mdc":{"trace_id":"26242f945af80b044a60226af00211fb","trace_flags":"01","span_id ...继续阅读 (4)

前言最近在给opentelemetry-java-instrumentation提交了一个PR，是关于给 gRPC 新增四个 metrics：rpc.client.request.size: 客户端请求包大小rpc.client.response.size：客户端收到的响应包大小rpc.server.request.size：服务端收到的请求包大小rpc.server.response.size：服务端响应的请求包大小这个 PR 的主要目的就是能够在指标监控中拿到RPC请求的包大小，而这里的关键就是如何才能拿到这些包的大小。首先支持的是gRPC（目前在云原生领域使用的最多），其余的 RPC 理论上也是可以支持的：在实现的过程中我也比较好奇OpenTelemetry框架是如何给gRPC请求创建span调用链的，如下图所示：这是一个 gRPC 远程调用，java-demo 是 gRPC 的客户端，k8s-combat 是 gRPC 的服务端在开始之前我们可以根据OpenTelemetry的运行原理大概猜测下它的实现过程。首先我们应用可以创建这些链路信息的前提是：使用了OpenTelemetry提供的javaagent，这个 agent 的原理是在运行时使用了byte-buddy增强了我们应用的字节码，在这些字节码中代理业务逻辑，从而可以在不影响业务的前提下增强我们的代码（只要就是创建 ...继续阅读 (14)

前言在上一篇文章：OpenTelemetry 实战：从零实现分布式链路追踪讲解了链路相关的实战，本次我们继续跟进如何使用 OpenTelemetry 集成 metrics 监控。建议对指标监控不太熟的朋友可以先查看这篇前菜文章：从 Prometheus 到 OpenTelemetry：指标监控的演进与实践名称作用语言版本java-demo发送 gRPC 请求的客户端Javaopentelemetry-agent: 2.4.0/SpringBoot: 2.7.14k8s-combat提供 gRPC 服务的服务端Golanggo.opentelemetry.io/otel: 1.28/ Go: 1.22Jaegertrace 存储的服务端以及 TraceUI 展示Golangjaegertracing/all-in-one:1.56opentelemetry-collector-contribOpenTelemetry 的 collector 服务端，用于收集 trace/metrics/logs 然后写入到远端存储Golangotel/opentelemetry-collector-contrib:0.98.0Prometheus作为 metrics 的存储和展示组件，也可以用VictoriaMetrics等兼容 ...继续阅读 (13)

背景之前写过一篇从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅的文章，主要是从概念上讲解了 Trace 在 OpenTelemetry 的中的场景和使用。也写过一篇实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术：如何从一个 demo 开始集成 OpenTelemetry。但还是有不少小伙伴反馈说无法快速上手（可能也是这个 demo 的项目比较多），于是我准备从 0 开始从真实的代码一步步带大家集成OpenTelemetry，因为 OpenTelemetry 本身是跨多种语言的，所以也会以两种语言为（Java、Golang）主进行讲解。使用这两种语言主要是因为 Java 几乎全是自动埋点，而 Golang 因为语言特性，大部分都得硬编码埋点；覆盖到这两种场景后其他语言也是类似的，顶多只是 API 名称有些许区别。在这个过程中也会穿插一些 OpenTelemetry 的原理，希望整个过程下来大家可以在项目中实际运用起来，同时也能知其所以然。项目结构在这个过程中会涉及到以下项目：名称作用语言版本java-demo发送 gRPC 请求的客户端Javaopentelemetry-agent: 2.4.0/SpringBoot: 2.7.14k8s-combat提供 gRPC 服务的服务端Golanggo.opentelemetry.i ...继续阅读 (24)

之前分享过如何快速上手开源项目以及如何在开源项目里做集成测试，但还没有讲过具体的实操。今天来详细讲讲如何写单元测试。🤔什么情况下需要单元测试这个大家应该是有共识的，对于一些功能单一、核心逻辑、同时变化不频繁的公开函数才有必要做单元测试。对于业务复杂、链路繁琐但也是核心流程的功能通常建议做 e2e 测试，这样可以保证最终测试结果的一致性。💀具体案例我们都知道单测的主要目的是模拟执行你写过的每一行代码，目的就是要覆盖到主要分支，做到自己的每一行代码都心中有数。下面以Apache HertzBeat的一些单测为例，讲解如何编写一个单元测试。先以一个最简单的org.apache.hertzbeat.collector.collect.udp.UdpCollectImpl#preCheck函数测试为例。这里的preCheck函数就是简单的检测做参数校验。测试时只要我们手动将metrics设置为null就可以进入这个 if 条件。123456789101112131415@ExtendWith(MockitoExtension.class)classUdpCollectImplTest{@InjectMocksprivateUdpCollectImpl udpCollect;@TestvoidtestPreCheck(){ListaliasField =newArrayLi ...继续阅读 (24)

背景由于我在公司内部负责维护Pulsar，需要时不时的升级Pulsar版本从而和社区保持一致。而每次升级过程都需要做相同的步骤：安装一个新版本的集群触发功能性测试触发性能测试查看监控是否正常应用有无异常日志流量是否正常各个组件的内存占用是否正常写入延迟是否正常命令行工具以上的流程步骤最好是全部一键完成，我们只需要人工检测下监控是否正常即可。于是我便写了一个命令行工具，执行流程如下：12345678910111213141516171819pulsar-upgrade-cli -h ok | at 10:33:18A cli app for upgrading PulsarUsage:pulsar-upgrade-cli [command]Available Commands:completion Generate the autocompletion script for the specified shellhelp Help about any commandinstall install a target versionscale scale sta ...继续阅读 (25)

前段时间在pulsar-client-go社区里看到这么一个issue：1234567891011121314151617181920212223242526import"github.com/apache/pulsar-client-go/pulsar"client, err := pulsar.NewClient(pulsar.ClientOptions{URL:"pulsar://localhost:6650",})iferr !=nil{log.Fatal(err)}consumer, err := client.Subscribe(pulsar.ConsumerOptions{Topic:"persistent://public/default/mq-topic-1",SubscriptionName:"sub-1",Type: pulsar.Shared,ReceiverQueueSize:0,})iferr !=nil{log.Fatal(err)}// 小于等于 0 时会设置为 1000const(defaultReceiverQueueSize =1000)ifoptions.ReceiverQueueSize <=0{options.Receive ...继续阅读 (27)

前段时间接到一个需求，希望可以监控 Nginx 的运行状态。我们都知道 Nginx 作为一个流行的 Web 服务器提供了多种能力，包括反向代理、负载均衡；也支持了许多协议，包括：gRPChttpWebSocket 等作为一个流量入口的中间件，对其的监控就显得至关重要了。市面上也有一些现成的产品可以监控 Nginx，比如知名的监控服务商datadog也提供了 Nginx 的监控。但是我这是一个内网服务，并不能使用这些外部的云厂商，所有就只能在内部搭建 Nginx 的监控服务了。不过 Nginx 默认情况下并没有提供/metrics的 endpoint，但好在它提供了一个额外的模块：stub_status可以用于获取监控数据。12345678910111213server{listen80;server_name_;location/status{stub_statuson;access_logoff;}location/{root/usr/share/nginx/html;indexindex.htmlindex.htm;}}这样访问http://127.0.0.1:80/status就可以拿到一些基本的运行数据。但这个格式明显不是 Prometheus 所支持的 metrics 格式，无法直接将数据采集到 Promethe ...继续阅读 (29)

背景Pulsar 有提供一个查询 Broker 负载的接口：1234567891011121314151617181920/*** Get load for this broker.**@return*@throwsPulsarAdminException*/LoadManagerReportgetLoadReport()throwsPulsarAdminException;publicinterfaceLoadManagerReportextendsServiceLookupData{ResourceUsagegetCpu();ResourceUsagegetMemory();ResourceUsagegetDirectMemory();ResourceUsagegetBandwidthIn();ResourceUsagegetBandwidthOut();}可以返回一些 broker 的负载数据，比如 CPU、内存、流量之类的数据。我目前碰到的问题是目前会遇到部分节点的负债不平衡，导致资源占用不均衡，所以想要手动查询所有节点的负载数据，然后人工进行负载。理论上这些数据是在运行时实时计算的数据，如果对于单机的倒还好说，每次请求这个接口直接实时计算一次就可以了。但对于集群的服务来说会有多个节点，目前 Pulsar 提供的这个接口只能查询指定节点的负载数据，也就是 ...继续阅读 (32)

最近收到了Apache Pulsar和Apache HertzBeat社区的邀请邮件，成为了这两个项目的Committer。一路走来我从最开始的打游击战的闲散人员到如今活跃在各个开源项目里的“老兵”，用现在流行的话来说Apache的这两个Committer就相当于是拿到了编制，进入了正规军。下面就分享一下我的个人开源经历，希望对想要参与开源或者已经在其中的开发者有所帮助。我的 GitHub 开源故事初识 GitHub我这个Github账号是在 15 年 9月份注册的，那时候刚出来参与工作。其实在这之前我压根没有听说过 GitHub、对开源也是知之甚少；只是知道老师和同事经常让我在网上可以下载到一些第三方包（现在回想起来几乎都是好 Apache 的提供的包）来解决日常的一些常见需求。当时只是觉得非常方便，没想到大部分的工作互联网上都有相关的解决方案。直到第二年也就是 16 年我才提交第一行代码，记得当时是需要和同学共享一些代码。在学校的时候大家都是把文件打包然后通过 QQ 发送的，因为我之前在 GitHub 上看到大家都是把源码公开的，所以当时的想法是不是可以直接使用 GitHub 把代码发给同学，这样就省去了打包解压的步骤了。现在想想还好都是一些非业务代码，不然就违反公司安全规定了。所以其实自己没有任何开源的概念，只是觉得分享代码很方便。后续在网上看了Richard Matthew ...继续阅读 (24)

之前有朋友问如何做集成测试，今天就重点讲讲这个集成测试在开源项目中是如何做的。通常是需要对外提供服务的开源项目都需要集成测试：PulsarKafkaDubbo 等而只提供本地类库的项目通常只需要编写单元测试即可：HutoolApache Commmon以我接触到的服务型应用主要分为两类：一个是 Java 应用一个是 Golang 应用。🐳GolangGolang 因为工具链没有 Java 那么强大，所以大部分的集成测试的功能都是通过编写 Makefile 和 shell 脚本实现的。还是以我熟悉的 Pulsar 的 go-client 为例，它在 GitHub 的集成测试是通过 GitHub action 触发的，定义如下：最终调用的是 Makefile 中的 test 命令，并且把需要测试的 Golang 版本传入进去。Dockerfile：这个镜像简单来说就是将 Pulsar 的镜像作为基础运行镜像（这里面包含了 Pulsar 的服务端），然后将这个 pulsar-client-go 的代码复制进去编译。接着运行：1cd /pulsar/pulsar-client-go && ./scripts/run-ci.sh也就是测试脚本。测试脚本的逻辑也很简单：启动 pulsar 服务端运行测试代码因为所有的测试代码里连接服务端的地址都是localhost，所以可以直接连接。通过这里的 ...继续阅读 (35)

🧰Helm 的作用在开始前需要先对 kubernetes Operator 有个简单的认识。以为我们在编写部署一些简单Deployment的时候只需要自己编写一个 yaml 文件然后kubectl apply即可。123456789101112131415161718192021222324252627apiVersion:apps/v1kind:Deploymentmetadata:labels:app:k8s-combatname:k8s-combatspec:replicas:1selector:matchLabels:app:k8s-combattemplate:metadata:labels:app:k8s-combatspec:containers:-name:k8s-combatimage:crossoverjie/k8s-combat:v1imagePullPolicy:Alwaysresources:limits:cpu:"1"memory:300Mirequests:cpu:"0.1"memory:30Mi1kubectl apply -f deployment.yaml这对于一些并不复杂的项目来说完全够用了，但组件一多就比较麻烦了。这里以 Apache Pulsar 为例：它的核心组件有:BrokerProxyZookeeperBookkeeperProme ...继续阅读 (32)

原文链接：https://medium.com/@andreiboar/5-small-tips-i-recently-learned-in-go-cf52d50cf129让编译器计算数组数量我们在 Go 通常很少使用数组 arrays，一般使用切片 Slice 来代替；但是当你需要使用的时候，如果你对需要指定数量大小感到很烦时可以使用[...]让编译器自动帮我们计算数组大小：123456789101112packagemainimport"fmt"funcmain(){arr := [3]int{1,2,3}sameArr := [...]int{1,2,3}// Use ... instead of 3// Arrays are equivalentfmt.Println(arr)fmt.Println(sameArr)}使用 go run . 替换 go run main.go每当我用 Go 写第一行代码时，我都习惯于开始写main.go:1234567891011packagemainimport"fmt"funcmain(){sayHello()}funcsayHello(){fmt.Println("Hello!")}但是当main ...继续阅读 (32)

以前有写过两篇文章来简单聊过如何做开源的事情，最近我自己组了一个社区里面也有不少朋友对开源感兴趣，于是我便根据自己的经验系统的梳理了一些关于开源的事情。新手如何快速参与开源项目手把手教你为开源项目贡献代码有兴趣的可以先看看之前这两篇。🔎如何找到自己感兴趣的开源项目首先第一步先想清楚自己搞开源的目的是什么：参考社区大佬的代码，提升技术丰富个人履历，提高面试通过率更功利一点就是想成为某个项目的Committer/PMC单纯喜欢分享，热爱开源，认可开源改变世界💪。我人为前面三种都是一个目的，提升自己获得后续的好处；最后一种则是妥妥的纯热爱。以我个人来说，我两者都沾一点；我相信大部分人都是前面三类的目的，到这里我可能要先浇点冷水。往往一个开源项目从你熟悉它开始到提第一个 PR 然后到合并中间经历的时间可能是大大超出你的预期的。特别是越大型越专业的项目（我相信你也是想加入这类有一定知名度的项目）。因为开源社区大部分都是执行异步沟通，与即时通讯的快速反馈不同，甚至还有不少 reviewer 处于不同的时区。所以一开始就想做好心理预期，不要指望着我给某个项目提交一个很牛逼的功能，然后他们快速 review 合并，然后给你 commit 权限。而且有不少开源项目是由某一个公司主导的，比如（Pulsar、Golang、Kafka），他们可能对于外部社区来的新手并不那么上心，一个 PR 晾在 ...继续阅读 (34)

背景在上一篇《从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅》中在最后提到在做一些 Trace 的定制开发。到现在差不多算是完成了，可以和大家分享一下。我们的需求是这样的：假设现在有三个服务：ServiceA、ServiceB、ServiceCServiceA对外提供了一个 http 接口request，在这个接口会调用ServiceB的order订单接口创建订单，同时serviceB调用serviceC的 pay 接口。整个调用关系如上图所示。默认情况下 span 中的 attribute 会记录当前 span 的一些信息，比如：这些都是当前一些当前 span 内置的信息，比如当前 gRPC 接口的一些基本数据：服务名、ip、端口等信息。但这里并没有上游的一些信息，虽然我们可以通过 Jaeger 的树状图得知上游是哪个应用调用过来的，但是一旦某个 span 下有多个子 span 的调用，就没办法很直观知道这个子 span 的上游是由谁发起的调用。比如如下这个链路：当一个调用链非常长，同时也非常复杂时，没办法第一时间知道某一个 span 的上游到底是谁发起的，需要手动一层层的去折叠，或者全靠眼睛去找。预期效果为此我们希望的效果是可以通过给每一个子 span 中加入两个 attribute，来标明它的父调用来源。比如在 serviceB 中的所有 span 中 ...继续阅读 (37)

在上一篇：从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅我们讲解了 Trace 的一些核心概念：TraceSpanContextBaggage 等这次我们来讲另一个话题Metrics。背景关于 metrics 我最早接触相关概念的就是 prometheus，它是第二个加入 CNCF（云原生）社区的项目（第一个是 kubernetes），可见在云原生领域 Metrics 指标监控从诞生之初就是一个非常重要的组件。现实也确实如此，如今只要使用到了 kubernetes 相关的项目，对其监控就是必不可少的。当然也不止是云原生的项目才需要 Metrics 指标监控，我们任何一个业务都是需要的，不然我们的服务运行对开发运维来说都是一个黑盒，无法知道此时系统的运行情况，因此才需要我们的业务系统将一些关键运行指标暴露出来。业务数据：比如订单的增长率、销售金额等业务数据；同时还有应用自身的资源占用情况：QPSLatency内存CPU 等信息。在使用 OpenTelemetry 之前，因为 prometheus 是这部分的绝对标准，所以我们通常都会使用 prometheus 的包来暴露这些指标：123456789101112The clientio.prometheussimpleclient0.16.0Hotspot JVM metricsio.prometheussimp ...继续阅读 (39)

在之前写过两篇比较系统的关于 OpenTelemetry 的文章：OpenTelemetry 实践指南：历史、架构与基本概念实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术从基本概念到如何部署 demo 实战了解 OpenTelemetry，从那个 demo 中也可以得知整个 OpenTelemetry 体系的复杂性，包含了太多的组件和概念。为了能更清晰的了解每个关键组件的作用以及原理，我打算分为几期来讲解 OpenTelemetry 的三个核心组件：TraceMetricsLogs首先以 Trace 讲起。Trace开始之前还是先复习一下 Trace 的历史背景。如今现代的分布式追踪的起源源自于 Google 在 2010 年发布的一篇论文：Dapper, a Large-Scale Distributed Systems Tracing Infrastructure在这篇论文中提出了分布式追踪的几个核心概念：TraceSpanSpan 的一些基础数据结构可视化追踪以及展示之后 Twitter 受到了 Dapper 的启发开源了现在我们熟知的Zipkin，包含了存储和可视化 UI 展示我们的追踪链路。Uber 也在 2015 年开源了Jaeger项目，它的功能和 Zipkin 类似，但目前我们用的较多的还是 Jaeger；现在已经成为 CNCF 的托管项目。 ...继续阅读 (51)

原文链接:https://overcast.blog/13-kubernetes-tricks-you-didnt-know-647de6364472使用 PreStop 优雅关闭 Pod123456789101112apiVersion:v1kind:Podmetadata:name:graceful-shutdown-examplespec:containers:-name:sample-containerimage:nginxlifecycle:preStop:exec:command:["/bin/sh","-c","sleep 30 && nginx -s quit"]PreStop 允许 Pod 在终止前执行一个命令或者是脚本，使用它就可以在应用退出前释放一些资源，确保应用可以优雅退出。比如可以在 Nginx 的 Pod 退出前将当前的请求执行完毕。使用临时容器调试 Pod临时容器可以不修改一个运行的容器的前提下调试容器，可以很方便的调试一些生产环境的 bug，可以避免重启应用。1kubectl alpha debug -it podname --image=busybox --target=containername生产环境谨慎使用，只有在当前环境下无法排查问题的时候才使用。基于自定义的 Metrics 自动扩容Podkubernetes 是提供了 HPA 机制可以 ...继续阅读 (37)

前言在上一篇文章OpenTelemetry 实践指南：历史、架构与基本概念中回顾了可观测性的历史以及介绍了一些 OpenTelemetry 的基础概念，同时也介绍了 OpenTelemetry 社区常用的开源项目。基础背景知识了解后，这篇就来介绍一下使用 OpenTelemetry 如何实战部署应用，同时在一个可视化页面查看 trace、metric 等信息。项目介绍我们参考官方文档构建几个 spring boot 、Golang 项目再配合 Agent 其实也可以很方便的集成 OpenTelemetry。但是要完整的体验 OpenTelemetry 的所有功能，包含 trace、logs、metrics，还有社区这么多语言的支持其实还是比较麻烦的。我们还需要单独部署 collector、存储的 backend service 等组件、包括 trace UI 展示所需要的 Jaeger，metric 所需要的 grafana 等。这些所有东西都自己从头弄的话还是比较费时，不过好在社区已经将这些步骤都考虑到了。特地为大家写了一个opentelemetry-demo。这个项目模拟了一个微服务版本的电子商城，主要包含了以下一些项目：ServiceLanguageDescriptionaccountingserviceGo处理和计算订单数据adserviceJava广告服务cartserv ...继续阅读 (41)

背景之前陆续写过一些和 OpenTelemetry 相关的文章：实战：如何优雅的从 Skywalking 切换到 OpenTelemetry实战：如何编写一个 OpenTelemetry Extensions从一个 JDK21+OpenTelemetry 不兼容的问题讲起这些内容的前提是最好有一些 OpenTelemetry 的背景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门科普，方便一些对 OpenTelemetry 不是那么熟的朋友快速掌握一些 OpenTelemetry 的基本概念。历史发展早在OpenTelemetry诞生之前可观测性这个概念就一直存在了，我记得我最早接触到这个概念是在 16 年当时的公司所使用的一个产品：pinpoint现如今这个项目依然比较活跃。依然还记得当时通过它可以直接看到项目调用的拓扑图，在时间坐标上框出高延迟的点就能列出这些请求，同时还能查看此时的运行日志。这样强大的功能对于一个刚工作一年的小白来说冲击力实属太大了一点。后来才了解到 pinpoint 属于 APM 这类产品，类似的产品还有：Apache SkyWalking美团的 CAT 等他们都是可以用于性能分析和链路追踪的产品，到后来公司的运维层面也接入过 Zabbix、open-falcon 之类的产品：17之后全面切换到 spring boot 时，也用过社区提供的spring ...继续阅读 (37)

背景前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。但这个不生效的前置条件有点多：JDK 的版本得在 18+SpringBoot3.x还在额外再配合使用-javaagent:opentelemetry-javaagent.jar使用，也就是 OpenTelemetry 提供的 agent。才会导致自定义的InetAddressResolverProvider无法正常工作。在复现这个问题之前先简单介绍下java.net.spi.InetAddressResolverProvider这个 SPI；它是在 JDK18 之后才提供的，在这之前我们使用InetAddress的内置解析器来解析主机名和 IP 地址，但这个解析器之前是不可以自定义的。在某些场景下会不太方便，比如我们需要请求order.service这个域名时希望可以请求到某一个具体 IP 地址上，我们可以自己配置 host ，或者使用服务发现机制来实现。但现在通过InetAddressResolverProvider就可以定义在请求这个域名的时候返回一个我们预期的 IP 地址。同时由于它是一个 SPI，所以我们只需要编写一个第三方包，任何项目依赖它之后在发 ...继续阅读 (55)

背景最近在给opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个e2e test.因为在当前的版本下，只要给 deployment 打上了instrumentation.opentelemetry.io/inject-java: "true"这类注解就会给该 deployment 注入 agent。但没办法指定不同的 agent 版本（或者不同的环境变量），所以希望可以新增一个选择器，同时可以针对不同的 deployment 维护不同版本的Instrumentation(是用于控制需要注入 deployment 的资源)；这样就可以灵活控制了。在这之前我其实也很少做 kubernetes 的 operator 开发，对如何做 kubernetes 的 e2e 测试也比较陌生，好在社区提供了详细的贡献文档。安装简单来说需要两个关键组件：kind: kubernetes in docker，是可以在本地利用 docker 启动一个 kubernetes 集群的工具，通常用于在本地进行开发、测试关于 kubernetes 相关的功能。安装 kind 的前提是本地已经安装好了 docker。chainsaw: 一个 e2e 测试框架，提供了声明式的方式定义测试用例，也有着丰富断言功能。他们的安装都很简单 ...继续阅读 (59)

背景前两天收到业务反馈有一个 topic 的分区消息堆积了：根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。排查通过排查，发现确实是在一点多的时候消息堆积了（后面是修复之后堆积开始下降）。于是我在刚才堆积处查看了一条堆积消息的列表：获取到其中一条消息的messageId.这里本质上使用的是 pulsar-admin 的 API。org.apache.pulsar.client.admin.Topics#peekMessages再通过这条消息的 id （为了演示，这里的 messageId 可能不一样）在我们的 pulsar 消息链路系统中找到了消息的发送链路：通过这个链路会发现消息一直在推送，但就是没有收到客户端的 ACK 响应。相关的消息链路埋点可以参考这里：如何编写一个 Pulsar Broker Interceptor 插件简单来说就是在以下几个 broker 提供的拦截器接口加上埋点数据即可：messageProducedmessageDispatchedmessageAcked既然知道了是客户端没有响应 ACK，那就得知道客户端此时在干什么。首先排查了 JVM 内存、CPU 等监控情况，发现一切都挺正常的，这段时间没有明显的尖刺。Arthas 排查于是便准备使用 arthas 查看下线程的运行情 ...继续阅读 (53)

当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。同时在 kubernetes 中的日志来源也比传统虚拟机多，比如可能有容器、kubernetes 自身的事件、日志等。我们的日志采集方案也得与时俱进，kubernetes 的官方博客有介绍提供一下几种方案：节点采集第一种方案是在节点中采集日志，我们知道 kubernetes 是分为 master 调度节点以及 worker 工作节点；我们的应用都是运行在 worker 节点中的。在 kubernetes 环境中更推荐使用标准的 stdout/stderr 作为日志输出，这样 kubernetes 更方便做统一处理。以我们的 docker 运行时为例，默认情况下我们的标准输入文件会写入到/var/log目录中。如上图所示：我们可以在 kubernetes 的每一个 worker 节点中部署一个DaemonSet类型的采集器（filebeat 等），再由他去采集该节点下/var/log的日志，最终由他将日志采集后发往日志处理的后端，比如 elasticsearch 等组件中。这种方案的好处是资源占用较 ...继续阅读 (73)