OpenTelemetry 实践指南：历史、架构与基本概念
背景之前陆续写过一些和 OpenTelemetry 相关的文章： 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry 实战：如何编写一个 OpenTelemetry Extensions 从一个 JDK21+OpenTelemetry 不兼容的问题讲起 这些内容的前提是最好有一些 OpenTelemetry 的背景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门
从一个 JDK21+OpenTelemetry 不兼容的问题讲起
背景前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。 但这个不生效的前置条件有点多： JDK 的版本得在 18+ SpringBoot3.x 还在额外再配合使用 -javaagent:opentelemetry-javaa
如何对 kubernetes 应用做 e2e(端到端) 测试
背景最近在给 opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个 e2e test. 因为在当前的版本下，只要给 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 这类注解就会给该 deployment
一次消息队列异常堆积的排查
背景前两天收到业务反馈有一个 topic 的分区消息堆积了：根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。
在 kubernetes 环境下如何采集日志
当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。 这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。 可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。 同时在 kubernetes 中的日志来源也比传统虚拟机多，比如可能有容器、kubernetes 自身的事件、日志
实战：如何编写一个 OpenTelemetry Extensions
前言前段时间我们从 SkyWalking 切换到了 OpenTelemetry ，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。 我也写了相关介绍文章：实战：如何优雅的从 SkyWalking 切换到 OpenTelemetry 好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发，我们可以不用去修改社区发行版：ope
2024年的云原生架构需要哪些技术栈
背景时间过得很快啊，一转眼已经到了 2024 年，还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate) 框架就能应付大部分面试了。 12345现在 CS 专业的新同学估计都没听说过 SSM😢 恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍，技术栈也有由最开始的单体应用+