在上一篇：从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅我们讲解了 Trace 的一些核心概念：

• Trace
• Span
• Context
• Baggage 等

这次我们来讲另一个话题 Metrics。

在之前写过两篇比较系统的关于 OpenTelemetry 的文章：

• OpenTelemetry 实践指南：历史、架构与基本概念
• 实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术

从基本概念到如何部署 demo 实战了解 OpenTelemetry，从那个 demo 中也可以得知整个 OpenTelemetry 体系的复杂性，包含了太多的组件和概念。

为了能更清晰的了解每个关键组件的作用以及原理，我打算分为几期来讲解 OpenTelemetry 的三个核心组件：

• Trace
• Metrics
• Logs

首先以 Trace 讲起。

原文链接: https://overcast.blog/13-kubernetes-tricks-you-didnt-know-647de6364472

使用 PreStop 优雅关闭 Pod

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Pod
metadata:
  name: graceful-shutdown-example
spec:
  containers:
  - name: sample-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 30 && nginx -s quit"]

PreStop 允许 Pod 在终止前执行一个命令或者是脚本，使用它就可以在应用退出前释放一些资源，确保应用可以优雅退出。

比如可以在 Nginx 的 Pod 退出前将当前的请求执行完毕。

前言

在上一篇文章 OpenTelemetry 实践指南：历史、架构与基本概念中回顾了可观测性的历史以及介绍了一些 OpenTelemetry 的基础概念，同时也介绍了 OpenTelemetry 社区常用的开源项目。

基础背景知识了解后，这篇就来介绍一下使用 OpenTelemetry 如何实战部署应用，同时在一个可视化页面查看 trace、metric 等信息。

背景

之前陆续写过一些和 OpenTelemetry 相关的文章：

• 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry
• 实战：如何编写一个 OpenTelemetry Extensions
• 从一个 JDK21+OpenTelemetry 不兼容的问题讲起

这些内容的前提是最好有一些 OpenTelemetry 的背景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门科普，方便一些对 OpenTelemetry 不是那么熟的朋友快速掌握一些 OpenTelemetry 的基本概念。

背景

前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。

但这个不生效的前置条件有点多：

• JDK 的版本得在 18+
• SpringBoot3.x
• 还在额外再配合使用 -javaagent:opentelemetry-javaagent.jar 使用，也就是 OpenTelemetry 提供的 agent。

才会导致自定义的 InetAddressResolverProvider 无法正常工作。

背景

最近在给 opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个 e2e test.

因为在当前的版本下，只要给 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 这类注解就会给该 deployment 注入 agent。
但没办法指定不同的 agent 版本（或者不同的环境变量），所以希望可以新增一个选择器，同时可以针对不同的 deployment 维护不同版本的 Instrumentation(是用于控制需要注入 deployment 的资源)；这样就可以灵活控制了。

背景

前两天收到业务反馈有一个 topic 的分区消息堆积了：

根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。

当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。

这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。

可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。

同时在 kubernetes 中的日志来源也比传统虚拟机多，比如可能有容器、kubernetes 自身的事件、日志等。

前言

前段时间我们从 SkyWalking 切换到了 OpenTelemetry ，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。

我也写了相关介绍文章：
实战：如何优雅的从 SkyWalking 切换到 OpenTelemetry

好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发，我们可以不用去修改社区发行版：opentelemetry-javaagent.jar 的源码也可以扩展其中的能力。

比如可以：

• 修改一些 trace，某些 span 不想记录等。
• 新增 metrics